[lkml]   [2009]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] vmscan: limit concurrent reclaimers in shrink_zone
    On Thu, Dec 10, 2009 at 06:56:26PM -0500, Rik van Riel wrote:
    > Under very heavy multi-process workloads, like AIM7, the VM can
    > get into trouble in a variety of ways. The trouble start when
    > there are hundreds, or even thousands of processes active in the
    > page reclaim code.
    > Not only can the system suffer enormous slowdowns because of
    > lock contention (and conditional reschedules) between thousands
    > of processes in the page reclaim code, but each process will try
    > to free up to SWAP_CLUSTER_MAX pages, even when the system already
    > has lots of memory free. In Larry's case, this resulted in over
    > 6000 processes fighting over locks in the page reclaim code, even
    > though the system already had 1.5GB of free memory.
    > It should be possible to avoid both of those issues at once, by
    > simply limiting how many processes are active in the page reclaim
    > code simultaneously.

    This sounds like a very good argument against using direct reclaim at
    all. It reminds a bit of the issue we had in XFS with lots of processes
    pushing the AIL and causing massive slowdowns due to lock contention
    and cacheline bonucing. Moving all the AIL pushing into a dedicated
    thread solved that nicely. In the VM we already have that dedicated
    per-node kswapd thread, so moving off as much as possible work to
    should be equivalent.

    Of course any of this kind of tuning really requires a lot of testing
    and benchrmarking to verify those assumptions.

     \ /
      Last update: 2009-12-14 14:17    [W:0.020 / U:16.000 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site