1. 26 9月, 2006 1 次提交
  2. 23 6月, 2006 1 次提交
  3. 16 5月, 2006 1 次提交
  4. 26 4月, 2006 1 次提交
  5. 29 3月, 2006 1 次提交
  6. 26 3月, 2006 3 次提交
    • P
      [PATCH] slab: optimize constant-size kzalloc calls · 40c07ae8
      Pekka Enberg 提交于
      As suggested by Eric Dumazet, optimize kzalloc() calls that pass a
      compile-time constant size.  Please note that the patch increases kernel
      text slightly (~200 bytes for defconfig on x86).
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      40c07ae8
    • P
      [PATCH] slab: introduce kmem_cache_zalloc allocator · a8c0f9a4
      Pekka Enberg 提交于
      Introduce a memory-zeroing variant of kmem_cache_alloc.  The allocator
      already exits in XFS and there are potential users for it so this patch
      makes the allocator available for the general public.
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a8c0f9a4
    • A
      [PATCH] slab: implement /proc/slab_allocators · 871751e2
      Al Viro 提交于
      Implement /proc/slab_allocators.   It produces output like:
      
      idr_layer_cache: 80 idr_pre_get+0x33/0x4e
      buffer_head: 2555 alloc_buffer_head+0x20/0x75
      mm_struct: 9 mm_alloc+0x1e/0x42
      mm_struct: 20 dup_mm+0x36/0x370
      vm_area_struct: 384 dup_mm+0x18f/0x370
      vm_area_struct: 151 do_mmap_pgoff+0x2e0/0x7c3
      vm_area_struct: 1 split_vma+0x5a/0x10e
      vm_area_struct: 11 do_brk+0x206/0x2e2
      vm_area_struct: 2 copy_vma+0xda/0x142
      vm_area_struct: 9 setup_arg_pages+0x99/0x214
      fs_cache: 8 copy_fs_struct+0x21/0x133
      fs_cache: 29 copy_process+0xf38/0x10e3
      files_cache: 30 alloc_files+0x1b/0xcf
      signal_cache: 81 copy_process+0xbaa/0x10e3
      sighand_cache: 77 copy_process+0xe65/0x10e3
      sighand_cache: 1 de_thread+0x4d/0x5f8
      anon_vma: 241 anon_vma_prepare+0xd9/0xf3
      size-2048: 1 add_sect_attrs+0x5f/0x145
      size-2048: 2 journal_init_revoke+0x99/0x302
      size-2048: 2 journal_init_revoke+0x137/0x302
      size-2048: 2 journal_init_inode+0xf9/0x1c4
      
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Alexander Nyberg <alexn@telia.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Christoph Lameter <clameter@engr.sgi.com>
      Cc: Ravikiran Thirumalai <kiran@scalex86.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      DESC
      slab-leaks3-locking-fix
      EDESC
      From: Andrew Morton <akpm@osdl.org>
      
      Update for slab-remove-cachep-spinlock.patch
      
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Alexander Nyberg <alexn@telia.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Christoph Lameter <clameter@engr.sgi.com>
      Cc: Ravikiran Thirumalai <kiran@scalex86.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      871751e2
  7. 24 3月, 2006 1 次提交
    • P
      [PATCH] cpuset memory spread slab cache implementation · 101a5001
      Paul Jackson 提交于
      Provide the slab cache infrastructure to support cpuset memory spreading.
      
      See the previous patches, cpuset_mem_spread, for an explanation of cpuset
      memory spreading.
      
      This patch provides a slab cache SLAB_MEM_SPREAD flag.  If set in the
      kmem_cache_create() call defining a slab cache, then any task marked with the
      process state flag PF_MEMSPREAD will spread memory page allocations for that
      cache over all the allowed nodes, instead of preferring the local (faulting)
      node.
      
      On systems not configured with CONFIG_NUMA, this results in no change to the
      page allocation code path for slab caches.
      
      On systems with cpusets configured in the kernel, but the "memory_spread"
      cpuset option not enabled for the current tasks cpuset, this adds a call to a
      cpuset routine and failed bit test of the processor state flag PF_SPREAD_SLAB.
      
      For tasks so marked, a second inline test is done for the slab cache flag
      SLAB_MEM_SPREAD, and if that is set and if the allocation is not
      in_interrupt(), this adds a call to to a cpuset routine that computes which of
      the tasks mems_allowed nodes should be preferred for this allocation.
      
      ==> This patch adds another hook into the performance critical
          code path to allocating objects from the slab cache, in the
          ____cache_alloc() chunk, below.  The next patch optimizes this
          hook, reducing the impact of the combined mempolicy plus memory
          spreading hooks on this critical code path to a single check
          against the tasks task_struct flags word.
      
      This patch provides the generic slab flags and logic needed to apply memory
      spreading to a particular slab.
      
      A subsequent patch will mark a few specific slab caches for this placement
      policy.
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      101a5001
  8. 22 3月, 2006 2 次提交
    • C
      [PATCH] slab: Remove SLAB_NO_REAP option · ac2b898c
      Christoph Lameter 提交于
      SLAB_NO_REAP is documented as an option that will cause this slab not to be
      reaped under memory pressure.  However, that is not what happens.  The only
      thing that SLAB_NO_REAP controls at the moment is the reclaim of the unused
      slab elements that were allocated in batch in cache_reap().  Cache_reap()
      is run every few seconds independently of memory pressure.
      
      Could we remove the whole thing?  Its only used by three slabs anyways and
      I cannot find a reason for having this option.
      
      There is an additional problem with SLAB_NO_REAP.  If set then the recovery
      of objects from alien caches is switched off.  Objects not freed on the
      same node where they were initially allocated will only be reused if a
      certain amount of objects accumulates from one alien node (not very likely)
      or if the cache is explicitly shrunk.  (Strangely __cache_shrink does not
      check for SLAB_NO_REAP)
      
      Getting rid of SLAB_NO_REAP fixes the problems with alien cache freeing.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Mark Fasheh <mark.fasheh@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ac2b898c
    • A
      [PATCH] kcalloc(): INT_MAX -> ULONG_MAX · b50ec7d8
      Adrian Bunk 提交于
      Since size_t has the same size as a long on all architectures, it's enough
      for overflow checks to check against ULONG_MAX.
      
      This change could allow a compiler better optimization (especially in the
      n=1 case).
      
      The practical effect seems to be positive, but quite small:
      
          text           data     bss      dec            hex filename
      21762380        5859870 1848928 29471178        1c1b1ca vmlinux-old
      21762211        5859870 1848928 29471009        1c1b121 vmlinux-patched
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b50ec7d8
  9. 02 2月, 2006 1 次提交
  10. 09 1月, 2006 1 次提交
    • M
      [PATCH] slob: introduce the SLOB allocator · 10cef602
      Matt Mackall 提交于
      configurable replacement for slab allocator
      
      This adds a CONFIG_SLAB option under CONFIG_EMBEDDED.  When CONFIG_SLAB is
      disabled, the kernel falls back to using the 'SLOB' allocator.
      
      SLOB is a traditional K&R/UNIX allocator with a SLAB emulation layer,
      similar to the original Linux kmalloc allocator that SLAB replaced.  It's
      signicantly smaller code and is more memory efficient.  But like all
      similar allocators, it scales poorly and suffers from fragmentation more
      than SLAB, so it's only appropriate for small systems.
      
      It's been tested extensively in the Linux-tiny tree.  I've also
      stress-tested it with make -j 8 compiles on a 3G SMP+PREEMPT box (not
      recommended).
      
      Here's a comparison for otherwise identical builds, showing SLOB saving
      nearly half a megabyte of RAM:
      
      $ size vmlinux*
         text    data     bss     dec     hex filename
      3336372  529360  190812 4056544  3de5e0 vmlinux-slab
      3323208  527948  190684 4041840  3dac70 vmlinux-slob
      
      $ size mm/{slab,slob}.o
         text    data     bss     dec     hex filename
        13221     752      48   14021    36c5 mm/slab.o
         1896      52       8    1956     7a4 mm/slob.o
      
      /proc/meminfo:
                        SLAB          SLOB      delta
      MemTotal:        27964 kB      27980 kB     +16 kB
      MemFree:         24596 kB      25092 kB    +496 kB
      Buffers:            36 kB         36 kB       0 kB
      Cached:           1188 kB       1188 kB       0 kB
      SwapCached:          0 kB          0 kB       0 kB
      Active:            608 kB        600 kB      -8 kB
      Inactive:          808 kB        812 kB      +4 kB
      HighTotal:           0 kB          0 kB       0 kB
      HighFree:            0 kB          0 kB       0 kB
      LowTotal:        27964 kB      27980 kB     +16 kB
      LowFree:         24596 kB      25092 kB    +496 kB
      SwapTotal:           0 kB          0 kB       0 kB
      SwapFree:            0 kB          0 kB       0 kB
      Dirty:               4 kB         12 kB      +8 kB
      Writeback:           0 kB          0 kB       0 kB
      Mapped:            560 kB        556 kB      -4 kB
      Slab:             1756 kB          0 kB   -1756 kB
      CommitLimit:     13980 kB      13988 kB      +8 kB
      Committed_AS:     4208 kB       4208 kB       0 kB
      PageTables:         28 kB         28 kB       0 kB
      VmallocTotal:  1007312 kB    1007312 kB       0 kB
      VmallocUsed:        48 kB         48 kB       0 kB
      VmallocChunk:  1007264 kB    1007264 kB       0 kB
      
      (this work has been sponsored in part by CELF)
      
      From: Ingo Molnar <mingo@elte.hu>
      
         Fix 32-bitness bugs in mm/slob.c.
      Signed-off-by: NMatt Mackall <mpm@selenic.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      10cef602
  11. 07 11月, 2005 1 次提交
  12. 28 10月, 2005 1 次提交
  13. 09 10月, 2005 1 次提交
  14. 11 9月, 2005 1 次提交
  15. 08 9月, 2005 1 次提交
  16. 28 7月, 2005 1 次提交
  17. 08 7月, 2005 1 次提交
  18. 19 6月, 2005 1 次提交
  19. 01 5月, 2005 1 次提交
    • M
      [PATCH] add kmalloc_node, inline cleanup · 97e2bde4
      Manfred Spraul 提交于
      The patch makes the following function calls available to allocate memory
      on a specific node without changing the basic operation of the slab
      allocator:
      
       kmem_cache_alloc_node(kmem_cache_t *cachep, unsigned int flags, int node);
       kmalloc_node(size_t size, unsigned int flags, int node);
      
      in a similar way to the existing node-blind functions:
      
       kmem_cache_alloc(kmem_cache_t *cachep, unsigned int flags);
       kmalloc(size, flags);
      
      kmem_cache_alloc_node was changed to pass flags and the node information
      through the existing layers of the slab allocator (which lead to some minor
      rearrangements).  The functions at the lowest layer (kmem_getpages,
      cache_grow) are already node aware.  Also __alloc_percpu can call
      kmalloc_node now.
      
      Performance measurements (using the pageset localization patch) yields:
      
      w/o patches:
      Tasks    jobs/min  jti  jobs/min/task      real       cpu
          1      484.27  100       484.2736     12.02      1.97   Wed Mar 30 20:50:43 2005
        100    25170.83   91       251.7083     23.12    150.10   Wed Mar 30 20:51:06 2005
        200    34601.66   84       173.0083     33.64    294.14   Wed Mar 30 20:51:40 2005
        300    37154.47   86       123.8482     46.99    436.56   Wed Mar 30 20:52:28 2005
        400    39839.82   80        99.5995     58.43    580.46   Wed Mar 30 20:53:27 2005
        500    40036.32   79        80.0726     72.68    728.60   Wed Mar 30 20:54:40 2005
        600    44074.21   79        73.4570     79.23    872.10   Wed Mar 30 20:55:59 2005
        700    44016.60   78        62.8809     92.56   1015.84   Wed Mar 30 20:57:32 2005
        800    40411.05   80        50.5138    115.22   1161.13   Wed Mar 30 20:59:28 2005
        900    42298.56   79        46.9984    123.83   1303.42   Wed Mar 30 21:01:33 2005
       1000    40955.05   80        40.9551    142.11   1441.92   Wed Mar 30 21:03:55 2005
      
      with pageset localization and slab API patches:
      Tasks    jobs/min  jti  jobs/min/task      real       cpu
          1      484.19  100       484.1930     12.02      1.98   Wed Mar 30 21:10:18 2005
        100    27428.25   92       274.2825     21.22    149.79   Wed Mar 30 21:10:40 2005
        200    37228.94   86       186.1447     31.27    293.49   Wed Mar 30 21:11:12 2005
        300    41725.42   85       139.0847     41.84    434.10   Wed Mar 30 21:11:54 2005
        400    43032.22   82       107.5805     54.10    582.06   Wed Mar 30 21:12:48 2005
        500    42211.23   83        84.4225     68.94    722.61   Wed Mar 30 21:13:58 2005
        600    40084.49   82        66.8075     87.12    873.11   Wed Mar 30 21:15:25 2005
        700    44169.30   79        63.0990     92.24   1008.77   Wed Mar 30 21:16:58 2005
        800    43097.94   79        53.8724    108.03   1155.88   Wed Mar 30 21:18:47 2005
        900    41846.75   79        46.4964    125.17   1303.38   Wed Mar 30 21:20:52 2005
       1000    40247.85   79        40.2478    144.60   1442.21   Wed Mar 30 21:23:17 2005
      Signed-off-by: NChristoph Lameter <christoph@lameter.com>
      Signed-off-by: NManfred Spraul <manfred@colorfullife.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      97e2bde4
  20. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4