On Sat, 17 Jun 2000, Cesar Eduardo Barros wrote:

On Fri, Jun 16, 2000 at 12:08:06PM -0300, Rik van Riel wrote:

quoted

On Fri, 16 Jun 2000, Mike Galbraith wrote:

quoted

On Wed, 14 Jun 2000, Alan Cox wrote:

quoted

Im interested to know if ac9/ac10 is the slow->fast change point

ac5 is definately the breaking point.  ac5 doesn't survive make
-j30.. starts swinging it's VM machette at everything in sight.  
Reversing the VM changes to ac4 restores throughput to test1
levels (11 minute build vs 21-26 minutes for everything
forward).

Exact tested reversals below.  FWIW, page aging doesn't seem to
be the problem.  I disabled that in ac17 and saw zero
difference.  (What may or not be a hint is that the /* Let
shrink_mmap handle this swapout. */ bit in vmscan.c does make a
consistent difference.  Reverting that bit alone takes a minimum
of 4 minutes off build time)

Interesting. Not delaying the swapout IO completely broke
performance under the tests I did here...

Delayed swapout vs. non-delayed swapouts was the difference
between 300 swapouts/s vs. 700 swapouts/s  (under a load
with 400 swapins/s).

I can understand it... When you wake up kswapd you need more
memory, and if you don't free it you will be called again. And
again. And again. (leaf is a slow box; both top and vmstat eat
20% CPU each with 1 second updates all the time). So it does
waste more time.

With ac4 I get the HDD light full on during the worse moments;
with ac16/18 it just sits there in kswapd and the light blinks
at about 1Hz.

I think the phenomenon you're seeing is not at all related
to deferred/non-deferred swapout. That doesn't have anything
to do with kswapd CPU usage.

The changed feedback loop in do_try_to_free_pages, however
may have something to do with this. It works well on machines
with more than 1 memory zone, but I can envision it breaking
on machines with just one zone...

I'm thinking of a way to fix this cleanly, I'll keep you posted.

quoted

OTOH, I can imagine it being better if you have a very small
LRU cache, something like less than 1/2 MB.

You can imagine it being better in some random rare condition I
don't care about. People have been noticing speed problems
related to kswapd. This is not microkernel research.

Please read my email before flaming. I am telling you I can
imagine non-deferred swapout (like what we had before) being
better when you have very little LRU cache, like on 8MB machines.

But now that you've told me you're not interested in 8MB machines
and value a flamewar more than a nicely running Linux box.  ;))

regards,

Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.

Wanna talk about the kernel?  irc.openprojects.net / #kernelnewbies
http://www.conectiva.com/		http://www.surriel.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/