On Sun, 26 Aug 2001, Marc A. Lehmann wrote:
> On Sun, Aug 26, 2001 at 10:48:05AM -0300, Rik van Riel <riel@conectiva.com.br> wrote:
> > This paper convinced me that doing just elevator sorting
> > is never enough ;)
>
> It must be enough, unfortunately ;)
Then you'll need to change the physical structure of
your disks to eliminate seek time. ;)
> > One thing you could do, in recent -ac kernels, is make the
> > maximum readahead size smaller by lowering the value in
> > /proc/sys/vm/max-readahead
>
> Yes, this indeed helps slightly (with the ac9 kernel I don't see the
> massive thrashing going on with the linus' ones anyway). Now the only
> thing left would be to be able to to that per access
Automatic scaling of readahead window and possibly more agressive
drop-behind could help your system load.
Could you give me a few (heavy load) lines of 'vmstat 5' output
so we have an idea of what kind of system load we're facing, and
the active/inactive memory lines from /proc/meminfo ?
> It seems that I can in excess of 4MB/s (sometimes 5MB/s) when using
> large bounce-buffers and disabling read-ahead completely under ac9. So
> something with the kernel read-ahead *is* going wrong, as the default
> read-ahead of 31 (pages? 124k) is very similar to my current
> read-buffer size of 128k. And enabling read-ahead and decreasing the
> user-space buffers gives abysmal performance again.
Indeed, something is going wrong ;)
Lets find out exactly what so we can iron out this bug
properly.
cheers,
Rik
-- IA64: a worthy successor to i860.http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to aardvark@nl.linux.org (spam digging piggy)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Aug 31 2001 - 21:00:20 EST