From: Christoph Lameter <clameter@sgi.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-mm@kvack.org
Subject: Re: drain_node_page(): Drain pages in batch units
Date: Tue, 21 Nov 2006 18:40:25 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0611211826080.588@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20061121175228.14eaf35b.akpm@osdl.org>
On Tue, 21 Nov 2006, Andrew Morton wrote:
> This will reduce the reaping rate. Potentially vastly.
It will fully drain in 6 reap cycles instead of in one. For a 32 node/ 64p
system this would mean 32* 2 <cache_reap time> * 6 ~ 6 minutes. Currently
we need one minute.
> Is that a good change? If so, why?
The reaping is only needed so that pages are not staying forever on
pagesets that are rarely used. The bigger the system the more numerous
those will become. Rarely used pagesets typically contain less than
"batch" pages on them anyways.
I'd be interested in alternative ideas on how to do this draining
(especialy since the slabifier does not need cache_reap() anymore). I
tinkered around with scheduling draining separarely via a workqueue. We
cannot add a workqueue for each pageset since we have about a million of
those on large system. Maybe add one per cpu and then do the draining
from there?
The slabifier has a workqueue per slab that is activated and running every
2 seconds but only if per cpu slabs for this slab cache active.
One of the key issues is that we still need to access off node data in
remote zones to get to this cpus pageset for that remote zone.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2006-11-22 2:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-21 20:56 Christoph Lameter
2006-11-22 1:52 ` Andrew Morton
2006-11-22 2:40 ` Christoph Lameter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0611211826080.588@schroedinger.engr.sgi.com \
--to=clameter@sgi.com \
--cc=akpm@osdl.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox