From: Andrea Arcangeli <andrea@suse.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@transmeta.com>,
MM mailing list <linux-mm@kvack.org>,
linux-kernel@vger.rutgers.edu
Subject: Re: [patch] balanced highmem subsystem under pre7-9
Date: Fri, 12 May 2000 14:57:27 +0200 (CEST) [thread overview]
Message-ID: <Pine.LNX.4.21.0005121419460.554-100000@inspiron> (raw)
In-Reply-To: <Pine.LNX.4.10.10005121307370.3348-100000@elte.hu>
On Fri, 12 May 2000, Ingo Molnar wrote:
>what bad effects? the LRU list of the pagecache is a completely
>independent mechanizm. Highmem pages are LRU-freed just as effectively as
>normal pages. The pagecache LRU list is not per-zone but (IMHO correctly)
>global, so the particular zone of highmem pages is completely transparent
It shouldn't be global but per-NUMA-node as I have in the classzone patch.
>and irrelevant to the LRU mechanizm. I cannot see any bad effects wrt. LRU
>recycling and the highmem zone here. (let me know if you ment some
>different recycling mechanizm)
See line 320 of filemap.c in 2.3.99-pre7-pre9. (ignore the fact it will
recycle 1 page, it's just because they didn't expected pages_high to be
zero)
>'balanced' means: 'keep X amount of highmem free'. What is your point in
>keeping free highmem around?
Assuming there is no point, you still want to free also from the highmem
zone while doing LRU aging of the cache.
And if you don't keep X amount of highmem free you'll break if an irq will
do a GFP_HIGHMEM allocation.
Note also that with highmem I don't mean not the memory between 1giga and
64giga, but the memory between 0 and 64giga. When you allocate with
GFP_HIGHUSER you ask to the MM a page between 0 and 64giga.
And in turn what is the point of keeping X amount of normal/regular memory
free? You just try to keep such X amount of memory free in the DMA zone,
so why you also try to keep it free on the normal zone? The problem is the
same.
Please read my emails on linux-mm of a few weeks ago about classzone
approch. I can forward them to linux-kernel if there is interest (I don't
know if there's a web archive but I guess there is).
If the current strict zone approch wouldn't be broken we could as well
choose to split the ZONE_HIGHMEM in 10/20 zones to scales 10/20 times
better during allocations, no? Is this argulemnt enough to make you to at
least ring a bell that the current design is flawed? The flaw is that we
pay that with drawbacks and by having the VM that does the wrong thing
because it have no enough information (it only see a little part of the
picture). You can't fix it without looking the whole picture (the
classzone).
Andrea
--
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-05-12 12:57 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-05-08 17:21 [PATCH] Recent VM fiasco - fixed Zlatko Calusic
2000-05-08 17:43 ` Rik van Riel
2000-05-08 18:16 ` Zlatko Calusic
2000-05-08 18:20 ` Linus Torvalds
2000-05-08 18:46 ` Rik van Riel
2000-05-08 18:53 ` Zlatko Calusic
2000-05-08 19:04 ` Rik van Riel
2000-05-09 7:56 ` Daniel Stone
2000-05-09 8:25 ` Christoph Rohland
2000-05-09 15:44 ` Linus Torvalds
2000-05-09 16:12 ` Simon Kirby
2000-05-09 17:42 ` Christoph Rohland
2000-05-09 19:50 ` Linus Torvalds
2000-05-10 11:25 ` Christoph Rohland
2000-05-10 11:50 ` Zlatko Calusic
2000-05-11 23:40 ` Mark Hahn
2000-05-10 4:05 ` James H. Cloos Jr.
2000-05-10 7:29 ` James H. Cloos Jr.
2000-05-11 0:16 ` Linus Torvalds
2000-05-11 0:32 ` Linus Torvalds
2000-05-11 16:36 ` [PATCH] Recent VM fiasco - fixed (pre7-9) Rajagopal Ananthanarayanan
2000-05-11 1:04 ` [PATCH] Recent VM fiasco - fixed Juan J. Quintela
2000-05-11 1:53 ` Simon Kirby
2000-05-11 7:23 ` Linus Torvalds
2000-05-11 14:17 ` Simon Kirby
2000-05-11 23:38 ` Simon Kirby
2000-05-12 0:09 ` Linus Torvalds
2000-05-12 2:51 ` [RFC][PATCH] shrink_mmap avoid list_del (Was: Re: [PATCH] Recent VM fiasco - fixed) Roger Larsson
2000-05-11 11:15 ` [PATCH] Recent VM fiasco - fixed Rik van Riel
2000-05-11 5:10 ` Linus Torvalds
2000-05-11 10:09 ` James H. Cloos Jr.
2000-05-11 17:25 ` Juan J. Quintela
2000-05-11 23:25 ` [patch] balanced highmem subsystem under pre7-9 Ingo Molnar
2000-05-11 23:46 ` Linus Torvalds
2000-05-12 0:08 ` Ingo Molnar
2000-05-12 0:15 ` Ingo Molnar
2000-05-12 9:02 ` Christoph Rohland
2000-05-12 9:56 ` Ingo Molnar
2000-05-12 11:49 ` Christoph Rohland
2000-05-12 16:12 ` Linus Torvalds
2000-05-12 10:57 ` Andrea Arcangeli
2000-05-12 12:11 ` Ingo Molnar
2000-05-12 12:57 ` Andrea Arcangeli [this message]
2000-05-12 13:20 ` Rik van Riel
2000-05-12 16:40 ` Ingo Molnar
2000-05-12 17:15 ` Rik van Riel
2000-05-12 18:15 ` Linus Torvalds
2000-05-12 18:53 ` Ingo Molnar
2000-05-12 19:06 ` Linus Torvalds
2000-05-12 19:36 ` Ingo Molnar
2000-05-12 19:40 ` Ingo Molnar
2000-05-12 19:54 ` Ingo Molnar
2000-05-12 22:48 ` Rik van Riel
2000-05-13 11:57 ` Stephen C. Tweedie
2000-05-13 12:03 ` Rik van Riel
2000-05-13 12:14 ` Ingo Molnar
2000-05-13 14:23 ` Ingo Molnar
2000-05-19 1:58 ` Andrea Arcangeli
2000-05-19 15:03 ` Rik van Riel
2000-05-19 16:08 ` Andrea Arcangeli
2000-05-19 17:05 ` Rik van Riel
2000-05-19 22:28 ` Linus Torvalds
2000-05-11 11:12 ` [PATCH] Recent VM fiasco - fixed Christoph Rohland
2000-05-11 17:38 ` Steve Dodd
2000-05-09 10:21 ` Rik van Riel
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.21.0005121419460.554-100000@inspiron \
--to=andrea@suse.de \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=torvalds@transmeta.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