[lkml]   [2001]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
On Wed, Jan 24, 2001 at 01:43:26AM +0100, Sasi Peter wrote:
> (30+ high speed streams from 4 disks does really need some caching).

This isn't obvious. Your working may not fit in cache and so the kernel
understand it's worthless to swapout stuff to make space to a polluted cache.

> Can't say, of these many daemons nothing can be swapped out (and should
> under I/O load)!

If you run `cp /dev/zero .` on a smart VM nothing must be swapped out even if
it generated nearly the maximal I/O flood possible. It's worthless to let a
polluted cache to grow. It won't help anyways and you'll run slower the next
time you'll have to pagein from swap.

It _enterely_ depends on the I/O load pattern if it worth to swapout or not
to make space for filesystem cache.

> The performance just used to be better, but the whole more instable.
> Be this, if this is the price for stability.

As said we can add bits of page aging (that can't destabilize anything and it
will only affect performance behaviour), but I'd prefer to be sure you really
get a slowdown due the new VM behaviour (because more aging if done without
multiqueue O(1) approch can introduces waste of CPU and cachelines in kernel
space), so could you try to kill notes and squid and the other unused stuff and
to see if you return to deliver performance as with the older kernels? I still
miss this important information (last thing you said me was that with 100mbyte
in cache it swapouts, and without knowing the details of the I/O pattern it
looked sane). After that I'd also like to know what happens with 2.4.0 that
uses multiqueue and that is also able to detect pollution and to avoid swapping
out in such case.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:18    [W:0.081 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site