From: "David S. Miller" <davem@redhat.com>
To: sct@redhat.com
Cc: sim@stormix.com, jgarzik@mandrakesoft.com, riel@nl.linux.org,
andrea@suse.de, linux-mm@kvack.org, bcrl@redhat.com,
linux-kernel@vger.rutgers.edu
Subject: Re: [PATCH] 2.3.99-pre6-3+ VM rebalancing
Date: Wed, 26 Apr 2000 04:25:23 -0700 [thread overview]
Message-ID: <200004261125.EAA12302@pizda.ninka.net> (raw)
In-Reply-To: <20000426120130.E3792@redhat.com> (sct@redhat.com)
On Tue, Apr 25, 2000 at 12:06:58PM -0700, Simon Kirby wrote:
>
> Sorry, I made a mistake there while writing..I was going to give an
> example and wrote 60 seconds, but I didn't actually mean to limit
> anything to 60 seconds. I just meant to make a really big global lru
> that contains everything including page cache and swap. :)
Doesn't work. If you do that, a "find / | grep ..." swaps out
everything in your entire system.
Getting the VM to respond properly in a way which doesn't freak out
in the mass-filescan case is non-trivial. Simple LRU over all pages
simply doesn't cut it.
I believe this is not true at all. Clean pages will be preferred to
toss simply because they are easier to get rid of. In fact, "find / |
grep" is a perfect example of a case where LRU'ing only clean page
cache pages will keep the free page pools in equilibrium and we won't
need to swap anything.
I can say this with confidence, because I actually implemented a one
day hack which centralized all of page cache, swap cache, and all
anonymous pages into the LRU, deleted the crap we call swap_out and
taught the LRU queue processing how to toss pages from user address
spaces. Since I gave a mapping to anonymous pages, this became a
doable and almost trivial task. In these hacks I also created a
multi-list LRU scheme (active, inactive, dirty) so that
try_to_free_pages already had the LRU pool pre-sorted, so it only had
to look at pages which were unreferenced at the onset of memory
pressure. When we're not paging, kswapd would wake up periodically
to do some LRU aging and populate the inactive/dirty LRU queues.
I have to be quite frank, and say that the FreeBSD people are pretty
much on target when they say that our swapping and paging stinks, it
really does.
I am of the opinion that vmscan.c:swap_out() is one of our biggest
problems, because it kills us in the case where a few processes have
a pagecache page mapped, haven't accessed it in a long time, and
swap_out doesn't unmap those pages in time for the LRU shrink_mmap
code to fully toss it. This happens even though these pages are
excellant candidates for freeing. So here is where I came to the
conclusion that LRU needs to have the capability of tossing arbitrary
pages from process address spaces. This is why in my experiental
hacks I just killed swap_out() completely, and taught LRU how to
do all of the things swap_out did. I could do this because the
LRU scanner could go from a page to all mappings of that page, even
for anonymous and swap pages.
Later,
David S. Miller
davem@redhat.com
--
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-26 11:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-04-23 2:08 [PATCH] 2.3.99-pre6-3+ VM rebalancing Rik van Riel
2000-04-25 1:25 ` Simon Kirby
2000-04-25 15:09 ` Rik van Riel
2000-04-25 15:59 ` Andrea Arcangeli
2000-04-25 17:20 ` Rik van Riel
2000-04-25 18:36 ` Simon Kirby
2000-04-25 18:59 ` Jeff Garzik
2000-04-25 19:06 ` Simon Kirby
2000-04-25 19:34 ` Rik van Riel
2000-04-26 11:01 ` Stephen C. Tweedie
2000-04-26 11:15 ` Rik van Riel
2000-04-26 12:29 ` Stephen C. Tweedie
2000-04-26 12:45 ` David S. Miller
2000-04-26 11:25 ` David S. Miller [this message]
2000-04-26 13:00 ` Stephen C. Tweedie
2000-04-26 13:11 ` David S. Miller
2000-04-26 15:23 ` Stephen C. Tweedie
2000-04-26 15:25 ` David S. Miller
2000-04-26 16:09 ` Stephen C. Tweedie
2000-04-27 20:28 ` Simon Kirby
2000-04-27 22:32 ` Jamie Lokier
2000-04-26 13:46 ` Rik van Riel
2000-04-26 14:33 ` David S. Miller
2000-04-26 16:31 ` Andi Kleen
2000-04-26 15:28 ` David S. Miller
2000-04-26 15:41 ` Andi Kleen
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=200004261125.EAA12302@pizda.ninka.net \
--to=davem@redhat.com \
--cc=andrea@suse.de \
--cc=bcrl@redhat.com \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=riel@nl.linux.org \
--cc=sct@redhat.com \
--cc=sim@stormix.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