lkml.org 
[lkml]   [2008]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] page reclaim throttle take2
On Tue, 26 Feb 2008 23:56:39 -0800 (PST)
David Rientjes <rientjes@google.com> wrote:

> On Wed, 27 Feb 2008, KAMEZAWA Hiroyuki wrote:
>
> > Hmm, but kswapd, which is main worker of page reclaiming, is per-node.
> > And reclaim is done based on zone.
> > per-zone/per-node throttling seems to make sense.
> >
>
> That's another argument for not introducing the sysctl; the number of
> nodes and zones are a static property of the machine that cannot change
> without a reboot (numa=fake, mem=, introducing movable zones, etc). We
> don't have node hotplug that can suddenly introduce additional zones from
> which to reclaim.

Hmm, do you know there is already zone-hotplug ? ;)
(Means, onlining new memory in new zone increase the # of zones.
Now, in our system, possible-node turns to be online nodes.)

> My point was that there doesn't appear to be any use case for tuning this
> via a sysctl that isn't simply attempting to workaround some other reclaim
> problem when the VM is stressed. If that's agreed upon, then deciding
> between a config option that is either per-cpu or per-node should be based
> on the benchmarks that you've run. At this time, it appears that per-node
> is the more advantageous.
>
I agree that what is the best is based on benchmark.
I like per-node, now.
I believe there will be some change when RvR's spilit-LRU patches are applied.

> > I know his environment has 4cpus per node but throttle to 3 was the best
> > number in his measurement. Then it seems num-per-cpu is excessive.
> > (At least, ratio(%) is better.)
>
> That seems to indicate that the NUMA topology is more important than lock
> contention for the reclaim throttle.
>
I hear that there is also I/O bottle-neck for page reclaiming, at last.


Thanks,
-Kame



\
 
 \ /
  Last update: 2008-02-27 09:09    [W:0.056 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site