From: Andi Kleen <ak@suse.de>
To: Christoph Lameter <clameter@sgi.com>
Cc: akpm@osdl.org, linux-mm@kvack.org
Subject: Re: [RFC] Avoid allocating interleave from almost full nodes
Date: Fri, 27 Oct 2006 21:12:11 -0700 [thread overview]
Message-ID: <200610272112.12118.ak@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0610271943540.10933@schroedinger.engr.sgi.com>
On Friday 27 October 2006 19:46, Christoph Lameter wrote:
> Interleave allocation often go over large sets of nodes. Some of the nodes
> may have tasks on them that heavily use memory. Overallocating those nodes
> may reduce performance of those tasks. It is better if we try to avoid
> nodes that have most of its memory used.
>
> This patch checks for the amount of free pages on a node. If it is lower
> than a predefined limit (in /proc/sys/kernel/min_interleave_ratio) then
> we avoid allocating from that node. We keep a bitmap of full nodes
> that is cleared every 2 seconds when the drain the pagesets for
> node 0.
>
> Should we find that all nodes are marked as full then we disregard
> the limit and allocate from the next node without any checks.
And when only one node is not full the interleaved allocations will
all go to that node? I'm not sure that's a good idea.
I suspect it will need some threshold like ">50% of all nodes full"
then disregard.
In general I think it's a bad hack: Who says the allocations
of the process who filled a node is more important than the interleaving
process? I think it would be better to keep them being equal citizens
and allocate interleaving everywhere.
-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:[~2006-10-28 4:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-28 2:46 Christoph Lameter
2006-10-28 4:12 ` Andi Kleen [this message]
2006-10-29 0:59 ` 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=200610272112.12118.ak@suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--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