[lkml]   [2011]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Kswapd in 3.2.0-rc5 is a CPU hog
    On Tue, Dec 27, 2011 at 01:44:05PM +0900, KAMEZAWA Hiroyuki wrote:
    > To me, it seems kswapd does usual work...reclaim small memory until free
    > gets enough. And it seems 'dd' allocates its memory from ZONE_DMA32 because
    > of gfp_t fallbacks.
    > Memo.
    > 1. why shrink_slab() should be called per zone, which is not zone aware.
    > Isn't it enough to call it per priority ?

    It is intended that it should be zone aware, but the current
    shrinkers only have global LRUs and hence cannot discriminate
    between objects from different zones easily. And if only a single
    node/zone is being scanned, then we still have to call shirnk_slab()
    to try to free objects in that zone/node, despite it's current
    global scope.

    I have some prototype patches that make the major slab caches and
    shrinkers zone/node aware - that is the eventual goal here - but
    first all the major slab cache LRUs need to be converted to be node
    aware first. Then we can pass a nodemask into shrink_slab() and down
    to the shrinkers so that those that have per-node LRUs can scan only
    the appropriate nodes for objects to free. This is someting that I'm
    working on in my spare time, but I have very little of that at the
    moment, unfortunately.

    > 2. what spinlock contention that perf showed ?
    > And if shrink_slab() doesn't consume cpu as trace shows, why perf
    > says shrink_slab() is heavy..

    There isn't any spin lock contention - it's just showing how
    expensive locking superblocks is when it's being done every few
    microseconds for no good reason.

    > 3. because 8/9 of memory is in DMA32, calling shrink_slab() frequently
    > at scanning NORMAL seems to be time wasting.

    Especially as the shrink_slab() calls are returning zero pages freed
    every single time (i.e. the slab caches are empty). kswapd needs to
    back off here, I think, or free more memory at a time. Only freeing
    100 pages at a time is pretty inefficient, esp. as we have 4 orders
    of magnitude more pages on the LRU and that is consuming >90% of


    Dave Chinner

     \ /
      Last update: 2011-12-28 22:37    [W:0.021 / U:20.644 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site