Is it someone's desktop or is it just a remote server / compile box?

FWIW, my armchair theory is that the VM mis-management is seen most
obviously for a desktop box, with say lots of piggish interactive apps
running.  E.g. takes 30 secs to de-iconify a netscape window.

I may be wrong, since the above description applied to the 2.1.120+
poor VM algorithm I mentioned earlier (ancient history I guess...).
There, if I had a

        tar ... | gzip > foo.tar.gz

pipeline running, involving say 50 MB of data, the kernel would
over-eagerly try to cache/buffer all of that data in RAM in case it
needed it again (as a good server might want to do). However, this
caused all the big interactive apps (netscape, acroread, xemacs) to
rapidly page out, making interactive response awful.

This scenario may not apply to 2.4.x series, but it may be something
close. Thankfully, I have not done more than 1 hr of work on a machine
running 2.4 kernel.

Karl


On Tue, 02 Oct 2001, [EMAIL PROTECTED] (Michael O'Donnell) wrote:
> 
> I can testify that not ALL instances of 2.4.x are
> broken.  One of the machines I use at work is an
> SMP Mac that normally has multiple users logged in
> running multiple simultaneous builds and generally
> beating on the system pretty thoroughly with heavy
> compute and I/O loads (kernel compiles) and memory
> loads high enough that we drive it into swap even
> though it has 512Mb of RAM.  It ran for nearly a
> year on 2.4.0-test10 and basically never went down
> except during power failures or for maintenance.
> We upgraded it to 2.4.10-pre8 approx 1 month ago
> and I see no difference in reliability so far.


**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************

Reply via email to