On Wed, Jan 24, 2001 at 04:05:12PM +0100, Sasi Peter wrote:
> > 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.
>
> But your understanding agrees on that the larger chunks for each stream
> we read into cache, the more efficient for this kind of RAID disk
> structure the read is, thus basically the more cache we have, the more
> bandwidth we can serve. (disks give more data in the same time with
> fewer long reads than with several shorter ones)
The size of the I/O requests doesn't grow linearly with with the size of the
cache, as far as you have some mbyte of cache you will also be able to sumbit
full sized requests to disk (512K per req on 2.4). In your workload you just
had enough memory for the readahead.
In general if your working set doesn't fit in cache, the size of the cache is
unrelated to the bandwith you get out of your RAID, infact if your working set
doesn't fit in cache you should not pass through the cache at all to get the
best performance and to save CPU cycles and L1 dcache and L2 cache (O_DIRECT).
> So might it have been an accidental behaviour of the previous kernels
> to swap out pages in favor of caching under high I/O pressure, but it
> was certainly a benefical behaviour.
I trust you this is the case for your workload, but make sure to not assume
that because there's less cache and no swap you're running slower, you may be
running _much_ faster instead ;).
> What should I test with? (2.4.0/1pre?)
latest pre patch is ok.
Andrea