Re: ~500 megs cached yet 2.6.5 goes into swap hell

[Tim Connors]

Andrew Morton <akpm@xxxxxxxx> said on Wed, 28 Apr 2004 18:40:08 -0700:
> Jeff Garzik <jgarzik@xxxxxxxxx> wrote:
> >  These are at the heart of the thread (or my point, at 
> > least) -- BloatyApp may be Oracle with a huge cache of its own, for 
> > which swapping out may be a huge mistake.  Or Mozilla.  After some 
> > amount of disk IO on my 512MB machine, Mozilla would be swapped out... 
> > when I had only been typing an email minutes before.
> 
> OK, so it takes four seconds to swap mozilla back in, and you noticed it.

Actually, about 20-30 seconds on all of my boxs (no, I have no idea
why so slow even on the P4 I have here - swapping has always seemed
overly slow on this machine, and yes, DMA is turned on) with a ~100MB
mozilla image (plus the parts of X that get swapped out and need to be
swapped in before the user sees any effect - X takes up about ~100MB
res memory typically here, since I tend to have so many apps with
cached pixmaps open and in current use).

> Did you notice that those three kernel builds you just did ran in twenty
> seconds less time because they had more cache available?  Nope.

Nope, because I never run 3 builds before rebooting - I do however run
a lot of software that only ever reads a file once (the file was
written on another host on the cluster, so the caching done at write
time is of no benefit to us here.

This is something that should be up to the admin, because the kernel
*cannot* know what I want. And I don't think /proc/.../swapiness is
enough to define what we want.

> > Regardless of /proc/sys/vm/swappiness, I think it's a valid concern of 
> > sysadmins who request "hard cache limit", because they are seeing 
> > pathological behavior such that apps get swapped out when cache is over 
> > 50% of all available memory.
> 
> We should be sceptical of this.  If they can provide *numbers* then fine. 
> Otherwise, the subjective "oh gee, that took a long time" seat-of-the-pants
> stuff does not impress.  If they want to feel better about it then sure,
> set swappiness to zero and live with less cache for the things which need
> it...

OK - I'll try to get around to giving you a vmstat 1 and maybe top
output, and timing things next time I run one of these big
visualisation jobs (it'd be very nice if this was all backported to
2.4, since this is what we are mostly using here -- I think I can find
a 2.6 machine though)...

-- 
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
My code is giving me mixed signals. SIGSEGV then SIGILL then SIGBUS. -- me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/