1. 21 Jun, 2005 4 commits
    • Wolfgang Wander's avatar
      [PATCH] Avoiding mmap fragmentation · 1363c3cd
      Wolfgang Wander authored
      
      
      Ingo recently introduced a great speedup for allocating new mmaps using the
      free_area_cache pointer which boosts the specweb SSL benchmark by 4-5% and
      causes huge performance increases in thread creation.
      
      The downside of this patch is that it does lead to fragmentation in the
      mmap-ed areas (visible via /proc/self/maps), such that some applications
      that work fine under 2.4 kernels quickly run out of memory on any 2.6
      kernel.
      
      The problem is twofold:
      
        1) the free_area_cache is used to continue a search for memory where
           the last search ended.  Before the change new areas were always
           searched from the base address on.
      
           So now new small areas are cluttering holes of all sizes
           throughout the whole mmap-able region whereas before small holes
           tended to close holes near the base leaving holes far from the base
           large and available for larger requests.
      
        2) the free_area_cache also is set to the location of the last
           munmap-ed area so in scenarios where we allocate e.g.  five regions of
           1K each, then free regions 4 2 3 in this order the next request for 1K
           will be placed in the position of the old region 3, whereas before we
           appended it to the still active region 1, placing it at the location
           of the old region 2.  Before we had 1 free region of 2K, now we only
           get two free regions of 1K -> fragmentation.
      
      The patch addresses thes issues by introducing yet another cache descriptor
      cached_hole_size that contains the largest known hole size below the
      current free_area_cache.  If a new request comes in the size is compared
      against the cached_hole_size and if the request can be filled with a hole
      below free_area_cache the search is started from the base instead.
      
      The results look promising: Whereas 2.6.12-rc4 fragments quickly and my
      (earlier posted) leakme.c test program terminates after 50000+ iterations
      with 96 distinct and fragmented maps in /proc/self/maps it performs nicely
      (as expected) with thread creation, Ingo's test_str02 with 20000 threads
      requires 0.7s system time.
      
      Taking out Ingo's patch (un-patch available per request) by basically
      deleting all mentions of free_area_cache from the kernel and starting the
      search for new memory always at the respective bases we observe: leakme
      terminates successfully with 11 distinctive hardly fragmented areas in
      /proc/self/maps but thread creating is gringdingly slow: 30+s(!) system
      time for Ingo's test_str02 with 20000 threads.
      
      Now - drumroll ;-) the appended patch works fine with leakme: it ends with
      only 7 distinct areas in /proc/self/maps and also thread creation seems
      sufficiently fast with 0.71s for 20000 threads.
      Signed-off-by: default avatarWolfgang Wander <wwc@rentec.com>
      Credit-to: "Richard Purdie" <rpurdie@rpsys.net>
      Signed-off-by: default avatarKen Chen <kenneth.w.chen@intel.com>
      Acked-by: Ingo Molnar <mingo@elte.hu> (partly)
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1363c3cd
    • Nikita Danilov's avatar
      [PATCH] mm: add /proc/zoneinfo · 295ab934
      Nikita Danilov authored
      
      
      Add /proc/zoneinfo file to display information about memory zones.  Useful
      to analyze VM behaviour.
      Signed-off-by: default avatarNikita Danilov <nikita@clusterfs.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      295ab934
    • Ingo Molnar's avatar
      [PATCH] smp_processor_id() cleanup · 39c715b7
      Ingo Molnar authored
      
      
      This patch implements a number of smp_processor_id() cleanup ideas that
      Arjan van de Ven and I came up with.
      
      The previous __smp_processor_id/_smp_processor_id/smp_processor_id API
      spaghetti was hard to follow both on the implementational and on the
      usage side.
      
      Some of the complexity arose from picking wrong names, some of the
      complexity comes from the fact that not all architectures defined
      __smp_processor_id.
      
      In the new code, there are two externally visible symbols:
      
       - smp_processor_id(): debug variant.
      
       - raw_smp_processor_id(): nondebug variant. Replaces all existing
         uses of _smp_processor_id() and __smp_processor_id(). Defined
         by every SMP architecture in include/asm-*/smp.h.
      
      There is one new internal symbol, dependent on DEBUG_PREEMPT:
      
       - debug_smp_processor_id(): internal debug variant, mapped to
                                   smp_processor_id().
      
      Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new
      lib/smp_processor_id.c file.  All related comments got updated and/or
      clarified.
      
      I have build/boot tested the following 8 .config combinations on x86:
      
       {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT}
      
      I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT.  (Other
      architectures are untested, but should work just fine.)
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarArjan van de Ven <arjan@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      39c715b7
    • Greg KH's avatar
      [PATCH] devfs: remove devfs from Kconfig preventing it from being built · 2c6e5a83
      Greg KH authored
      
      
      Here's a much smaller patch to simply disable devfs from the build.  If
      this goes well, and there are no complaints for a few weeks, I'll resend
      my big "devfs-die-die-die" series of patches that rip the whole thing
      out of the kernel tree.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2c6e5a83
  2. 20 Jun, 2005 8 commits
  3. 18 Jun, 2005 1 commit
  4. 16 Jun, 2005 1 commit
  5. 13 Jun, 2005 1 commit
  6. 09 Jun, 2005 1 commit
  7. 07 Jun, 2005 1 commit
    • Trond Myklebust's avatar
      [PATCH] NFS: Fix lookup intent handling · 1d6757fb
      Trond Myklebust authored
      
      
      We should never apply a lookup intent to anything other than the last
      path component in an open(), create() or access() call.
      
      Introduce the helper nfs_lookup_check_intent() which always returns
      zero if LOOKUP_CONTINUE or LOOKUP_PARENT are set, and returns the
      intent flags if we're on the last component of the lookup.
      By doing so, we fix a bug in open(O_EXCL), where we may end up
      optimizing away a real lookup of the parent directory.
      
      Problem noticed by Linda Dunaphant <linda.dunaphant@ccur.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1d6757fb
  8. 06 Jun, 2005 20 commits
  9. 04 Jun, 2005 1 commit
  10. 03 Jun, 2005 1 commit
    • Dave Kleikamp's avatar
      JFS: Fix compiler warning in jfs_logmgr.c · 72e3148a
      Dave Kleikamp authored
      
      
      fs/jfs/jfs_logmgr.c: In function `jfs_flush_journal':
      fs/jfs/jfs_logmgr.c:1632: warning: unused variable `mp'
      
      Some debug code in jfs_flush_journal does nothing when CONFIG_JFS_DEBUG
      is not defined.  Place the whole code segment within an ifdef to avoid
      unnecessary code to be compiled and the warning to be issued.
      Signed-off-by: default avatarDave Kleikamp <shaggy@austin.ibm.com>
      72e3148a
  11. 02 Jun, 2005 1 commit