From: Benjamin Redelings I <bredelin@ucla.edu>
To: linux-mm@kvack.org
Subject: Re: Happiness with t8-vmpatch4 (was Re: Does page-aging really work?)
Date: Sat, 16 Sep 2000 11:20:55 -0700 [thread overview]
Message-ID: <39C3BA07.9525723F@ucla.edu> (raw)
In-Reply-To: <Pine.LNX.4.21.0009160455260.1519-100000@duckman.distro.conectiva>
> This is indeed something to look at. Maybe we could give
> idle processes (sleeping for more than 20 seconds?) a
> "full" swap_cnt instead of swap_cnt = rss >> SWAP_SHIFT ?
This doesn't seem like it should be necessary. Right now, unused
processes ARE swapped preferentially (and completely) - its just that
swapping happens all of a sudden.
> And we could also start swapping a bit earlier when the
> cache is getting small, but I'm not sure about how to
> do this or exactly what performance benefits that would
> give ...
Evicting unused pages, either from the cache or from process can have
significant benefits on my machine (64Mb). Once swapping triggered,
20Mb were paged out, and stayed out. If these 20 Mb had been paged out
before, then I would have had 20Mb more cache to work with, which is 31%
of my memory. Go figure :)
While I agree with Byron that on low memory machines a smaller cache
can be a good thing - this DOES depend on the amount of RAM, and on the
workload. But on higher memory machines, more aggressiveness against
program code is good. Is there a way to make this adjust itself
dynamically - e.g. by measuring page faults?
Anyway - I have seen the behavior that Byron described, where 'used'
increases as a result of a 'find'. I think that maybe some more
aggressiveness against code pages (is that the right phrase?) might
solve the swapping problem and improve performance on low memory
machines also (since some code pages are simply evicted).
BTW, with test8-vmpatch4, I am gettings zillions of "VM: page_launder,
found pre-cleaned page ?!" messages.
-BenRI
--
"I want to be in the light, as He is in the Light,
I want to shine like the stars in the heavens." - DC Talk, "In the
Light"
Benjamin Redelings I <>< http://www.bol.ucla.edu/~bredelin/
--
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-09-16 18:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-09-08 21:34 Multiqueue VM Patch OK? Does page-aging really work? Benjamin Redelings I
2000-09-08 22:58 ` Rik van Riel
2000-09-16 7:09 ` Happiness with t8-vmpatch4 (was Re: Does page-aging really work?) Benjamin Redelings I
2000-09-16 7:57 ` Rik van Riel
2000-09-16 18:20 ` Benjamin Redelings I [this message]
2000-09-16 18:22 ` 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=39C3BA07.9525723F@ucla.edu \
--to=bredelin@ucla.edu \
--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