From: Andi Kleen <ak@suse.de>
To: Christoph Lameter <christoph@lameter.com>
Cc: Paul Jackson <pj@sgi.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: NUMA policy interface
Date: Thu, 4 Aug 2005 23:14:45 +0200 [thread overview]
Message-ID: <20050804211445.GE8266@wotan.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.62.0508041011590.7314@graphe.net>
> 1. BIND policy implemented in a way that fills up nodes from the lowest
> to the higest instead of allocating memory on the local node.
Hmm, there was a patch from PJ for that at some point. Not sure why it
was not merged. iirc the first implementation was too complex, but
there was a second reasonable one.
>
> 2. No separation between sys_ and do_ functions. Therefore difficult
> to use from kernel context.
set_fs(KERNEL_DS)
Some policies can be even set without that.
There are already kernel users BTW that prove you wrong.
> 3. Functions have weird side effect (f.e. get_nodes updating
> and using cpuset policies). Code is therefore difficult
> to maintain.
Agreed that should be cleaned up.
> 4. Uses bitmaps instead of nodemask_t.
Should be easy to fix if someone is motivated. When I wrote the code
nodemask_t didn't exist yet, and when it was merged it wasn't
converted over. Not a big deal.
>
> 5. No means to figure out where the memory was allocated although
> mempoliy.c implements scans over ptes that would allow that
> determination.
You lost me here.
>
> 6. Needs hook into page migration layer to move pages to either conform
> to policy or to move them menually.
Does it really? So far my feedback from all users I talked to is that they only
use a small subset of the functionality, even what is there is too complex.
Nobody with a real app so far has asked me for page migration.
There was one implementation of simple page migration in Steve L.'s patches,
but that was just because it was too hard to handle one corner case
otherwise.
> The long term impact of this missing functionality is already showing
> in the numbers of workarounds that I have seen at a various sites,
Examples?
-Andi
--
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>
next prev parent reply other threads:[~2005-08-04 21:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20050730181418.65caed1f.pj@sgi.com>
[not found] ` <Pine.LNX.4.62.0507301814540.31359@graphe.net>
[not found] ` <20050730190126.6bec9186.pj@sgi.com>
[not found] ` <Pine.LNX.4.62.0507301904420.31882@graphe.net>
[not found] ` <20050730191228.15b71533.pj@sgi.com>
[not found] ` <Pine.LNX.4.62.0508011147030.5541@graphe.net>
[not found] ` <20050803084849.GB10895@wotan.suse.de>
[not found] ` <Pine.LNX.4.62.0508040704590.3319@graphe.net>
[not found] ` <20050804142942.GY8266@wotan.suse.de>
[not found] ` <Pine.LNX.4.62.0508040922110.6650@graphe.net>
[not found] ` <20050804170803.GB8266@wotan.suse.de>
2005-08-04 17:34 ` Christoph Lameter
2005-08-04 21:14 ` Andi Kleen [this message]
2005-08-04 21:21 ` Christoph Lameter
2005-08-04 21:41 ` Andi Kleen
2005-08-04 22:19 ` Christoph Lameter
2005-08-04 22:44 ` Mike Kravetz
2005-08-04 23:40 ` Andi Kleen
2005-08-04 23:49 ` Christoph Lameter
2005-08-05 9:16 ` Andi Kleen
2005-08-05 14:52 ` Christoph Lameter
2005-08-05 14:58 ` Christoph Lameter
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=20050804211445.GE8266@wotan.suse.de \
--to=ak@suse.de \
--cc=christoph@lameter.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pj@sgi.com \
/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