1. 22 Dec, 2009 4 commits
    • Stefani Seibold's avatar
      kfifo: move struct kfifo in place · 45465487
      Stefani Seibold authored
      This is a new generic kernel FIFO implementation.
      
      The current kernel fifo API is not very widely used, because it has to
      many constrains.  Only 17 files in the current 2.6.31-rc5 used it.
      FIFO's are like list's a very basic thing and a kfifo API which handles
      the most use case would save a lot of development time and memory
      resources.
      
      I think this are the reasons why kfifo is not in use:
      
       - The API is to simple, important functions are missing
       - A fifo can be only allocated dynamically
       - There is a requirement of a spinlock whether you need it or not
       - There is no support for data records inside a fifo
      
      So I decided to extend the kfifo in a more generic way without blowing up
      the API to much.  The new API has the following benefits:
      
       - Generic usage: For kernel internal use and/or device driver.
       - Provide an API for the most use case.
       - Slim API: The whole API provides 25 functions.
       - Linux style habit.
       - DECLARE_KFIFO, DEFINE_KFIFO and INIT_KFIFO Macros
       - Direct copy_to_user from the fifo and copy_from_user into the fifo.
       - The kfifo itself is an in place member of the using data structure, this save an
         indirection access and does not waste the kernel allocator.
       - Lockless access: if only one reader and one writer is active on the fifo,
         which is the common use case, no additional locking is necessary.
       - Remove spinlock - give the user the freedom of choice what kind of locking to use if
         one is required.
       - Ability to handle records. Three type of records are supported:
         - Variable length records between 0-255 bytes, with a record size
           field of 1 bytes.
         - Variable length records between 0-65535 bytes, with a record size
           field of 2 bytes.
         - Fixed size records, which no record size field.
       - Preserve memory resource.
       - Performance!
       - Easy to use!
      
      This patch:
      
      Since most users want to have the kfifo as part of another object,
      reorganize the code to allow including struct kfifo in another data
      structure.  This requires changing the kfifo_alloc and kfifo_init
      prototypes so that we pass an existing kfifo pointer into them.  This
      patch changes the implementation and all existing users.
      
      [akpm@linux-foundation.org: fix warning]
      Signed-off-by: default avatarStefani Seibold <stefani@seibold.net>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Acked-by: default avatarAndi Kleen <ak@linux.intel.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      45465487
    • Randy Dunlap's avatar
      mm tracing: cleanup Documentation/trace/events-kmem.txt · 2ec91eec
      Randy Dunlap authored
      Clean up typos/grammos/spellos in events-kmem.txt.
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2ec91eec
    • Randy Dunlap's avatar
      lib/string.c: fix kernel-doc warnings · a6cd13f3
      Randy Dunlap authored
      Fix kernel-doc warnings (@arg name) in string.c::skip_spaces().
      
        Warning(lib/string.c:347): No description found for parameter 'str'
        Warning(lib/string.c:347): Excess function parameter 's' description in 'skip_spaces'
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a6cd13f3
    • Linus Torvalds's avatar
      Revert "time: Remove xtime_cache" · 83f57a11
      Linus Torvalds authored
      This reverts commit 7bc7d637, as
      requested by John Stultz. Quoting John:
      
       "Petr Titěra reported an issue where he saw odd atime regressions with
        2.6.33 where there were a full second worth of nanoseconds in the
        nanoseconds field.
      
        He also reviewed the time code and narrowed down the problem: unhandled
        overflow of the nanosecond field caused by rounding up the
        sub-nanosecond accumulated time.
      
        Details:
      
         * At the end of update_wall_time(), we currently round up the
        sub-nanosecond portion of accumulated time when storing it into xtime.
        This was added to avoid time inconsistencies caused when the
        sub-nanosecond portion was truncated when storing into xtime.
        Unfortunately we don't handle the possible second overflow caused by
        that rounding.
      
         * Previously the xtime_cache code hid this overflow by normalizing the
        xtime value when storing into the xtime_cache.
      
         * We could try to handle the second overflow after the rounding up, but
        since this affects the timekeeping's internal state, this would further
        complicate the next accumulation cycle, causing small errors in ntp
        steering. As much as I'd like to get rid of it, the xtime_cache code is
        known to work.
      
         * The correct fix is really to include the sub-nanosecond portion in the
        timekeeping accessor function, so we don't need to round up at during
        accumulation. This would greatly simplify the accumulation code.
        Unfortunately, we can't do this safely until the last three
        non-GENERIC_TIME arches (sparc32, arm, cris) are converted  (those
        patches are in -mm) and we kill off the spots where arches set xtime
        directly. This is all 2.6.34 material, so I think reverting the
        xtime_cache change is the best approach for now.
      
        Many thanks to Petr for both reporting and finding the issue!"
      Reported-by: default avatarPetr Titěra <P.Titera@century.cz>
      Requested-by: default avatarjohn stultz <johnstul@us.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      83f57a11
  2. 21 Dec, 2009 17 commits
  3. 20 Dec, 2009 6 commits
  4. 19 Dec, 2009 13 commits