1. 05 6月, 2014 1 次提交
    • V
      slab: get_online_mems for kmem_cache_{create,destroy,shrink} · 03afc0e2
      Vladimir Davydov 提交于
      When we create a sl[au]b cache, we allocate kmem_cache_node structures
      for each online NUMA node.  To handle nodes taken online/offline, we
      register memory hotplug notifier and allocate/free kmem_cache_node
      corresponding to the node that changes its state for each kmem cache.
      
      To synchronize between the two paths we hold the slab_mutex during both
      the cache creationg/destruction path and while tuning per-node parts of
      kmem caches in memory hotplug handler, but that's not quite right,
      because it does not guarantee that a newly created cache will have all
      kmem_cache_nodes initialized in case it races with memory hotplug.  For
      instance, in case of slub:
      
          CPU0                            CPU1
          ----                            ----
          kmem_cache_create:              online_pages:
           __kmem_cache_create:            slab_memory_callback:
                                            slab_mem_going_online_callback:
                                             lock slab_mutex
                                             for each slab_caches list entry
                                                 allocate kmem_cache node
                                             unlock slab_mutex
            lock slab_mutex
            init_kmem_cache_nodes:
             for_each_node_state(node, N_NORMAL_MEMORY)
                 allocate kmem_cache node
            add kmem_cache to slab_caches list
            unlock slab_mutex
                                          online_pages (continued):
                                           node_states_set_node
      
      As a result we'll get a kmem cache with not all kmem_cache_nodes
      allocated.
      
      To avoid issues like that we should hold get/put_online_mems() during
      the whole kmem cache creation/destruction/shrink paths, just like we
      deal with cpu hotplug.  This patch does the trick.
      
      Note, that after it's applied, there is no need in taking the slab_mutex
      for kmem_cache_shrink any more, so it is removed from there.
      Signed-off-by: NVladimir Davydov <vdavydov@parallels.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Xishi Qiu <qiuxishi@huawei.com>
      Cc: Jiang Liu <liuj97@gmail.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Wen Congyang <wency@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      03afc0e2
  2. 11 4月, 2014 1 次提交
  3. 05 9月, 2013 1 次提交
    • C
      mm/sl[aou]b: Move kmallocXXX functions to common code · f1b6eb6e
      Christoph Lameter 提交于
      The kmalloc* functions of all slab allcoators are similar now so
      lets move them into slab.h. This requires some function naming changes
      in slob.
      
      As a results of this patch there is a common set of functions for
      all allocators. Also means that kmalloc_large() is now available
      in general to perform large order allocations that go directly
      via the page allocator. kmalloc_large() can be substituted if
      kmalloc() throws warnings because of too large allocations.
      
      kmalloc_large() has exactly the same semantics as kmalloc but
      can only used for allocations > PAGE_SIZE.
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Signed-off-by: NPekka Enberg <penberg@kernel.org>
      f1b6eb6e
  4. 08 7月, 2013 1 次提交
    • S
      slob: Check for NULL pointer before calling ctor() · c1e854e9
      Steven Rostedt 提交于
      While doing some code inspection, I noticed that the slob constructor
      method can be called with a NULL pointer. If memory is tight and slob
      fails to allocate with slob_alloc() or slob_new_pages() it still calls
      the ctor() method with a NULL pointer. Looking at the first ctor()
      method I found, I noticed that it can not handle a NULL pointer (I'm
      sure others probably can't either):
      
      static void sighand_ctor(void *data)
      {
              struct sighand_struct *sighand = data;
      
              spin_lock_init(&sighand->siglock);
              init_waitqueue_head(&sighand->signalfd_wqh);
      }
      
      The solution is to only call the ctor() method if allocation succeeded.
      Acked-by: NChristoph Lameter <cl@linux.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NPekka Enberg <penberg@kernel.org>
      c1e854e9
  5. 07 7月, 2013 1 次提交
  6. 24 2月, 2013 1 次提交
  7. 19 12月, 2012 1 次提交
  8. 11 12月, 2012 1 次提交
  9. 31 10月, 2012 5 次提交
  10. 10 10月, 2012 1 次提交
    • A
      mm/slob: use min_t() to compare ARCH_SLAB_MINALIGN · baaf1dd4
      Arnd Bergmann 提交于
      The definition of ARCH_SLAB_MINALIGN is architecture dependent
      and can be either of type size_t or int. Comparing that value
      with ARCH_KMALLOC_MINALIGN can cause harmless warnings on
      platforms where they are different. Since both are always
      small positive integer numbers, using the size_t type to compare
      them is safe and gets rid of the warning.
      
      Without this patch, building ARM collie_defconfig results in:
      
      mm/slob.c: In function '__kmalloc_node':
      mm/slob.c:431:152: warning: comparison of distinct pointer types lacks a cast [enabled by default]
      mm/slob.c: In function 'kfree':
      mm/slob.c:484:153: warning: comparison of distinct pointer types lacks a cast [enabled by default]
      mm/slob.c: In function 'ksize':
      mm/slob.c:503:153: warning: comparison of distinct pointer types lacks a cast [enabled by default]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NChristoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      baaf1dd4
  11. 26 9月, 2012 1 次提交
    • D
      mm, slob: fix build breakage in __kmalloc_node_track_caller · 82bd5508
      David Rientjes 提交于
      On Sat, 8 Sep 2012, Ezequiel Garcia wrote:
      
      > @@ -454,15 +455,35 @@ void *__kmalloc_node(size_t size, gfp_t gfp, int node)
      >  			gfp |= __GFP_COMP;
      >  		ret = slob_new_pages(gfp, order, node);
      >
      > -		trace_kmalloc_node(_RET_IP_, ret,
      > +		trace_kmalloc_node(caller, ret,
      >  				   size, PAGE_SIZE << order, gfp, node);
      >  	}
      >
      >  	kmemleak_alloc(ret, size, 1, gfp);
      >  	return ret;
      >  }
      > +
      > +void *__kmalloc_node(size_t size, gfp_t gfp, int node)
      > +{
      > +	return __do_kmalloc_node(size, gfp, node, _RET_IP_);
      > +}
      >  EXPORT_SYMBOL(__kmalloc_node);
      >
      > +#ifdef CONFIG_TRACING
      > +void *__kmalloc_track_caller(size_t size, gfp_t gfp, unsigned long caller)
      > +{
      > +	return __do_kmalloc_node(size, gfp, NUMA_NO_NODE, caller);
      > +}
      > +
      > +#ifdef CONFIG_NUMA
      > +void *__kmalloc_node_track_caller(size_t size, gfp_t gfpflags,
      > +					int node, unsigned long caller)
      > +{
      > +	return __do_kmalloc_node(size, gfp, node, caller);
      > +}
      > +#endif
      
      This breaks Pekka's slab/next tree with this:
      
      mm/slob.c: In function '__kmalloc_node_track_caller':
      mm/slob.c:488: error: 'gfp' undeclared (first use in this function)
      mm/slob.c:488: error: (Each undeclared identifier is reported only once
      mm/slob.c:488: error: for each function it appears in.)
      
      mm, slob: fix build breakage in __kmalloc_node_track_caller
      
      "mm, slob: Add support for kmalloc_track_caller()" breaks the build
      because gfp is undeclared.  Fix it.
      Acked-by: NEzequiel Garcia <elezegarcia@gmail.com>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NPekka Enberg <penberg@kernel.org>
      82bd5508
  12. 25 9月, 2012 2 次提交
  13. 05 9月, 2012 8 次提交
  14. 12 7月, 2012 1 次提交
  15. 09 7月, 2012 2 次提交
  16. 14 6月, 2012 4 次提交
  17. 31 10月, 2011 1 次提交
  18. 27 7月, 2011 1 次提交
  19. 08 6月, 2011 1 次提交
    • S
      slob/lockdep: Fix gfp flags passed to lockdep · bd50cfa8
      Steven Rostedt 提交于
      Doing a ktest.pl randconfig, I stumbled across the following bug
      on boot up:
      
      ------------[ cut here ]------------
      WARNING: at /home/rostedt/work/autotest/nobackup/linux-test.git/kernel/lockdep.c:2649 lockdep_trace_alloc+0xed/0x100()
      Hardware name:
      Modules linked in:
      Pid: 0, comm: swapper Not tainted 3.0.0-rc1-test-00054-g1d68b67 #1
      Call Trace:
       [<ffffffff810626ad>] warn_slowpath_common+0xad/0xf0
       [<ffffffff8106270a>] warn_slowpath_null+0x1a/0x20
       [<ffffffff810b537d>] lockdep_trace_alloc+0xed/0x100
       [<ffffffff81182fb0>] __kmalloc_node+0x30/0x2f0
       [<ffffffff81153eda>] pcpu_mem_alloc+0x13a/0x180
       [<ffffffff82be022c>] percpu_init_late+0x48/0xc2
       [<ffffffff82bd630c>] ? mem_init+0xd8/0xe3
       [<ffffffff82bbcc73>] start_kernel+0x1c2/0x449
       [<ffffffff82bbc35c>] x86_64_start_reservations+0x163/0x167
       [<ffffffff82bbc493>] x86_64_start_kernel+0x133/0x142^M
      ---[ end trace a7919e7f17c0a725 ]---
      
      Then I ran a ktest.pl config_bisect and it came up with this config
      as the problem:
      
        CONFIG_SLOB
      
      Looking at what is different between SLOB and SLAB and SLUB, I found
      that the gfp flags are masked against gfp_allowed_mask in
      SLAB and SLUB, but not SLOB.
      
      On boot up, interrupts are disabled and lockdep will warn if some flags
      are set in gfp and interrupts are disabled. But these flags are masked
      off with the gfp_allowed_mask during boot. Because SLOB does not
      mask the flags against gfp_allowed_mask it triggers the warn on.
      
      Adding this mask fixes the bug. I also found that kmem_cache_alloc_node()
      was missing both the mask and the lockdep check, and that was added too.
      Acked-by: NMatt Mackall <mpm@selenic.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NPekka Enberg <penberg@kernel.org>
      bd50cfa8
  20. 24 1月, 2011 1 次提交
  21. 07 1月, 2011 1 次提交
  22. 02 10月, 2010 1 次提交
  23. 16 7月, 2010 1 次提交
    • B
      SLOB: Free objects to their own list · d602daba
      Bob Liu 提交于
      SLOB has alloced smaller objects from their own list in reduce overall external
      fragmentation and increase repeatability, free to their own list also.
      
      This is /proc/meminfo result in my test machine:
      
        without this patch:
        ===
        MemTotal:        1030720 kB
        MemFree:          750012 kB
        Buffers:           15496 kB
        Cached:           160396 kB
        SwapCached:            0 kB
        Active:           105024 kB
        Inactive:         145604 kB
        Active(anon):      74816 kB
        Inactive(anon):     2180 kB
        Active(file):      30208 kB
        Inactive(file):   143424 kB
        Unevictable:          16 kB
        ....
      
        with this patch:
        ===
        MemTotal:        1030720 kB
        MemFree:          751908 kB
        Buffers:           15492 kB
        Cached:           160280 kB
        SwapCached:            0 kB
        Active:           102720 kB
        Inactive:         146140 kB
        Active(anon):      73168 kB
        Inactive(anon):     2180 kB
        Active(file):      29552 kB
        Inactive(file):   143960 kB
        Unevictable:          16 kB
        ...
      
      The result shows an improvement of 1 MB!
      
      And when I tested it on a embeded system with 64 MB, I found this path is never
      called during kernel bootup.
      Acked-by: NMatt Mackall <mpm@selenic.com>
      Signed-off-by: NBob Liu <lliubbo@gmail.com>
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      d602daba
  24. 15 6月, 2010 1 次提交