From: Linus Torvalds <torvalds@transmeta.com>
To: riel@nl.linux.org
Cc: Andrea Arcangeli <andrea@suse.de>, linux-mm@kvack.org
Subject: Re: 2.3.x mem balancing
Date: Tue, 25 Apr 2000 11:53:25 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.10.10004251140450.847-100000@penguin.transmeta.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0004251437540.10408-100000@duckman.conectiva>
On Tue, 25 Apr 2000, Rik van Riel wrote:
>
> There's only one small addition that I'd like to see. Memory
> should be reclaimed on a more or less _global_ level because
> the processes in node 0 could use much less memory than the
> processes in node 1.
>
> Doing strict per-zone memory balancing in this case means that
> node 0 will have a bunch of idle pages lying around while node
> 1 is swapping...
This is why the page allocator has to have some knowledge about the whole
list of zones it allocates from.
The current one actually does that: before it tries to start paging it
first tries to find a zone that doesn't need any paging. So in this case
if node 0 is full, but there are empty pages in node 1, the page allocator
_will_ allocate from node 1 instead.
That is obviously not to say that the current code gets the heuristics
actually =right=. There are certainly bugs in the heuristics, as shown by
bad performance. David Miller pointed out that there also seems to be a
memory leak in the swap cache handling, so it can be more than just the
zone balancing that is wrong.
My argument is really not that the current code is perfect - it very
obviously is not. But I am 100% convinced that it is much better to have
independent memory-allocators with some common heuristics than it is to
try to force a global order on them.
Linus
--
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.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-04-25 18:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.21.0004250401520.4898-100000@alpha.random>
2000-04-25 16:57 ` Linus Torvalds
2000-04-25 17:50 ` Rik van Riel
2000-04-25 18:11 ` Jeff Garzik
2000-04-25 18:33 ` Rik van Riel
2000-04-25 18:53 ` Linus Torvalds [this message]
2000-04-25 19:27 ` Rik van Riel
2000-04-26 0:26 ` Linus Torvalds
2000-04-26 1:19 ` Rik van Riel
2000-04-26 1:07 ` Andrea Arcangeli
2000-04-26 2:10 ` Rik van Riel
2000-04-26 11:24 ` Stephen C. Tweedie
2000-04-26 16:44 ` Linus Torvalds
2000-04-26 17:13 ` Rik van Riel
2000-04-26 17:24 ` Linus Torvalds
2000-04-27 13:22 ` Stephen C. Tweedie
2000-04-26 14:19 ` Andrea Arcangeli
2000-04-26 16:52 ` Linus Torvalds
2000-04-26 17:49 ` Andrea Arcangeli
2000-04-26 16:03 Mark_H_Johnson.RTS
2000-04-26 17:06 ` Andrea Arcangeli
2000-04-26 17:36 ` Kanoj Sarcar
2000-04-26 21:58 ` Andrea Arcangeli
2000-04-26 17:43 ` Kanoj Sarcar
2000-04-26 19:06 frankeh
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.10.10004251140450.847-100000@penguin.transmeta.com \
--to=torvalds@transmeta.com \
--cc=andrea@suse.de \
--cc=linux-mm@kvack.org \
--cc=riel@nl.linux.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