1. 30 9月, 2006 1 次提交
    • D
      [PATCH] single bit flip detector · aa83aa40
      Dave Jones 提交于
      In cases where we detect a single bit has been flipped, we spew the usual
      slab corruption message, which users instantly think is a kernel bug.  In a
      lot of cases, single bit errors are down to bad memory, or other hardware
      failure.
      
      This patch adds an extra line to the slab debug messages in those cases, in
      the hope that users will try memtest before they report a bug.
      
      000: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
      Single bit error detected. Possibly bad RAM. Run memtest86.
      
      [akpm@osdl.org: cleanups]
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      aa83aa40
  2. 27 9月, 2006 3 次提交
    • C
      [PATCH] GFP_THISNODE for the slab allocator · 765c4507
      Christoph Lameter 提交于
      This patch insures that the slab node lists in the NUMA case only contain
      slabs that belong to that specific node.  All slab allocations use
      GFP_THISNODE when calling into the page allocator.  If an allocation fails
      then we fall back in the slab allocator according to the zonelists appropriate
      for a certain context.
      
      This allows a replication of the behavior of alloc_pages and alloc_pages node
      in the slab layer.
      
      Currently allocations requested from the page allocator may be redirected via
      cpusets to other nodes.  This results in remote pages on nodelists and that in
      turn results in interrupt latency issues during cache draining.  Plus the slab
      is handing out memory as local when it is really remote.
      
      Fallback for slab memory allocations will occur within the slab allocator and
      not in the page allocator.  This is necessary in order to be able to use the
      existing pools of objects on the nodes that we fall back to before adding more
      pages to a slab.
      
      The fallback function insures that the nodes we fall back to obey cpuset
      restrictions of the current context.  We do not allocate objects from outside
      of the current cpuset context like before.
      
      Note that the implementation of locality constraints within the slab allocator
      requires importing logic from the page allocator.  This is a mischmash that is
      not that great.  Other allocators (uncached allocator, vmalloc, huge pages)
      face similar problems and have similar minimal reimplementations of the basic
      fallback logic of the page allocator.  There is another way of implementing a
      slab by avoiding per node lists (see modular slab) but this wont work within
      the existing slab.
      
      V1->V2:
      - Use NUMA_BUILD to avoid #ifdef CONFIG_NUMA
      - Exploit GFP_THISNODE being 0 in the NON_NUMA case to avoid another
        #ifdef
      
      [akpm@osdl.org: build fix]
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      765c4507
    • C
      [PATCH] slab: fix kmalloc_node applying memory policies if nodeid == numa_node_id() · de3083ec
      Christoph Lameter 提交于
      kmalloc_node() falls back to ___cache_alloc() under certain conditions and
      at that point memory policies may be applied redirecting the allocation
      away from the current node.  Therefore kmalloc_node(...,numa_node_id()) or
      kmalloc_node(...,-1) may not return memory from the local node.
      
      Fix this by doing the policy check in __cache_alloc() instead of
      ____cache_alloc().
      
      This version here is a cleanup of Kiran's patch.
      
      - Tested on ia64.
      - Extra material removed.
      - Consolidate the exit path if alternate_node_alloc() returned an object.
      
      [akpm@osdl.org: warning fix]
      Signed-off-by: NAlok N Kataria <alok.kataria@calsoftinc.com>
      Signed-off-by: NRavikiran Thirumalai <kiran@scalex86.org>
      Signed-off-by: NShai Fultheim <shai@scalex86.org>
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      de3083ec
    • A
      [PATCH] Make kmem_cache_destroy() return void · 133d205a
      Alexey Dobriyan 提交于
      un-, de-, -free, -destroy, -exit, etc functions should in general return
      void.  Also,
      
      There is very little, say, filesystem driver code can do upon failed
      kmem_cache_destroy().  If it will be decided to BUG in this case, BUG
      should be put in generic code, instead.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      133d205a
  3. 26 9月, 2006 11 次提交
  4. 01 8月, 2006 2 次提交
  5. 14 7月, 2006 3 次提交
  6. 04 7月, 2006 1 次提交
  7. 01 7月, 2006 3 次提交
    • C
      [PATCH] slab: consolidate code to free slabs from freelist · ed11d9eb
      Christoph Lameter 提交于
      Post and discussion:
      http://marc.theaimsgroup.com/?t=115074342800003&r=1&w=2
      
      Code in __shrink_node() duplicates code in cache_reap()
      
      Add a new function drain_freelist that removes slabs with objects that are
      already free and use that in various places.
      
      This eliminates the __node_shrink() function and provides the interrupt
      holdoff reduction from slab_free to code that used to call __node_shrink.
      
      [akpm@osdl.org: build fixes]
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ed11d9eb
    • C
      [PATCH] zoned vm counters: conversion of nr_slab to per zone counter · 9a865ffa
      Christoph Lameter 提交于
      - Allows reclaim to access counter without looping over processor counts.
      
      - Allows accurate statistics on how many pages are used in a zone by
        the slab. This may become useful to balance slab allocations over
        various zones.
      
      [akpm@osdl.org: bugfix]
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9a865ffa
    • C
      [PATCH] zoned vm counters: basic ZVC (zoned vm counter) implementation · 2244b95a
      Christoph Lameter 提交于
      Per zone counter infrastructure
      
      The counters that we currently have for the VM are split per processor.  The
      processor however has not much to do with the zone these pages belong to.  We
      cannot tell f.e.  how many ZONE_DMA pages are dirty.
      
      So we are blind to potentially inbalances in the usage of memory in various
      zones.  F.e.  in a NUMA system we cannot tell how many pages are dirty on a
      particular node.  If we knew then we could put measures into the VM to balance
      the use of memory between different zones and different nodes in a NUMA
      system.  For example it would be possible to limit the dirty pages per node so
      that fast local memory is kept available even if a process is dirtying huge
      amounts of pages.
      
      Another example is zone reclaim.  We do not know how many unmapped pages exist
      per zone.  So we just have to try to reclaim.  If it is not working then we
      pause and try again later.  It would be better if we knew when it makes sense
      to reclaim unmapped pages from a zone.  This patchset allows the determination
      of the number of unmapped pages per zone.  We can remove the zone reclaim
      interval with the counters introduced here.
      
      Futhermore the ability to have various usage statistics available will allow
      the development of new NUMA balancing algorithms that may be able to improve
      the decision making in the scheduler of when to move a process to another node
      and hopefully will also enable automatic page migration through a user space
      program that can analyse the memory load distribution and then rebalance
      memory use in order to increase performance.
      
      The counter framework here implements differential counters for each processor
      in struct zone.  The differential counters are consolidated when a threshold
      is exceeded (like done in the current implementation for nr_pageache), when
      slab reaping occurs or when a consolidation function is called.
      
      Consolidation uses atomic operations and accumulates counters per zone in the
      zone structure and also globally in the vm_stat array.  VM functions can
      access the counts by simply indexing a global or zone specific array.
      
      The arrangement of counters in an array also simplifies processing when output
      has to be generated for /proc/*.
      
      Counters can be updated by calling inc/dec_zone_page_state or
      _inc/dec_zone_page_state analogous to *_page_state.  The second group of
      functions can be called if it is known that interrupts are disabled.
      
      Special optimized increment and decrement functions are provided.  These can
      avoid certain checks and use increment or decrement instructions that an
      architecture may provide.
      
      We also add a new CONFIG_DMA_IS_NORMAL that signifies that an architecture can
      do DMA to all memory and therefore ZONE_NORMAL will not be populated.  This is
      only currently set for IA64 SGI SN2 and currently only affects
      node_page_state().  In the best case node_page_state can be reduced to
      retrieving a single counter for the one zone on the node.
      
      [akpm@osdl.org: cleanups]
      [akpm@osdl.org: export vm_stat[] for filesystems]
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2244b95a
  8. 28 6月, 2006 5 次提交
  9. 23 6月, 2006 8 次提交
  10. 03 6月, 2006 1 次提交
    • I
      [PATCH] slab.c: fix offslab_limit bug · b1ab41c4
      Ingo Molnar 提交于
      mm/slab.c's offlab_limit logic is totally broken.
      
      Firstly, "offslab_limit" is a global variable while it should either be
      calculated in situ or should be passed in as a parameter.
      
      Secondly, the more serious problem with it is that the condition for
      calculating it:
      
                     if (!(OFF_SLAB(sizes->cs_cachep))) {
                             offslab_limit = sizes->cs_size - sizeof(struct slab);
                             offslab_limit /= sizeof(kmem_bufctl_t);
      
      is in total disconnect with the condition that makes use of it:
      
                     /* More than offslab_limit objects will cause problems */
                     if ((flags & CFLGS_OFF_SLAB) && num > offslab_limit)
                             break;
      
      but due to offslab_limit being a global variable this breakage was
      hidden.
      
      Up until lockdep came along and perturbed the slab sizes sufficiently so
      that the first off-slab cache would still see a (non-calculated) zero
      value for offslab_limit and would panic with:
      
        kmem_cache_create: couldn't create cache size-512.
      
        Call Trace:
         [<ffffffff8020a5b9>] show_trace+0x96/0x1c8
         [<ffffffff8020a8f0>] dump_stack+0x13/0x15
         [<ffffffff8022994f>] panic+0x39/0x21a
         [<ffffffff80270814>] kmem_cache_create+0x5a0/0x5d0
         [<ffffffff80aced62>] kmem_cache_init+0x193/0x379
         [<ffffffff80abf779>] start_kernel+0x17f/0x218
         [<ffffffff80abf263>] _sinittext+0x263/0x26a
      
        Kernel panic - not syncing: kmem_cache_create(): failed to create slab `size-512'
      
      Paolo Ornati's config on x86_64 managed to trigger it.
      
      The fix is to move the calculation to the place that makes use of it.
      This also makes slab.o 54 bytes smaller.
      
      Btw., the check itself is quite silly. Its intention is to test whether
      the number of objects per slab would be higher than the number of slab
      control pointers possible. In theory it could be triggered: if someone
      tried to allocate 4-byte objects cache and explicitly requested with
      CFLGS_OFF_SLAB. So i kept the check.
      
      Out of historic interest i checked how old this bug was and it's
      ancient, 10 years old! It is the oldest hidden and then truly triggering
      bugs i ever saw being fixed in the kernel!
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b1ab41c4
  11. 16 5月, 2006 2 次提交
    • R
      [PATCH] slab: Fix kmem_cache_destroy() on NUMA · a4523a8b
      Roland Dreier 提交于
      With CONFIG_NUMA set, kmem_cache_destroy() may fail and say "Can't
      free all objects."  The problem is caused by sequences such as the
      following (suppose we are on a NUMA machine with two nodes, 0 and 1):
      
       * Allocate an object from cache on node 0.
       * Free the object on node 1.  The object is put into node 1's alien
         array_cache for node 0.
       * Call kmem_cache_destroy(), which ultimately ends up in __cache_shrink().
       * __cache_shrink() does drain_cpu_caches(), which loops through all nodes.
         For each node it drains the shared array_cache and then handles the
         alien array_cache for the other node.
      
      However this means that node 0's shared array_cache will be drained,
      and then node 1 will move the contents of its alien[0] array_cache
      into that same shared array_cache.  node 0's shared array_cache is
      never looked at again, so the objects left there will appear to be in
      use when __cache_shrink() calls __node_shrink() for node 0.  So
      __node_shrink() will return 1 and kmem_cache_destroy() will fail.
      
      This patch fixes this by having drain_cpu_caches() do
      drain_alien_cache() on every node before it does drain_array() on the
      nodes' shared array_caches.
      
      The problem was originally reported by Or Gerlitz <ogerlitz@voltaire.com>.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Acked-by: NChristoph Lameter <clameter@sgi.com>
      Acked-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a4523a8b
    • M
      [PATCH] add slab_is_available() routine for boot code · 39d24e64
      Mike Kravetz 提交于
      slab_is_available() indicates slab based allocators are available for use.
      SPARSEMEM code needs to know this as it can be called at various times
      during the boot process.
      Signed-off-by: NMike Kravetz <kravetz@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      39d24e64