On Sun, 26 Aug 2001, Marc A. Lehmann wrote:
> On Sun, Aug 26, 2001 at 12:32:09AM -0300, Rik van Riel <riel@conectiva.com.br> wrote:
> > Reality check time indeed. If you propose that disabling
> > readahead should improve read performance something fishy
> > is going on ;)
>
> Actually, I also believe that. If you have no memory to store
> read-ahead data then your only chance is what I try to do: massively
> parallelize reads so the elevator can optimize what's possible and do
> no read-ahead whatsoever.
Margo Selzer wrote a nice paper on letting an elevator
algorithm take care of request sorting. Only at the point
where several thousand requests were queued and latency
to get something from disk grew to about 30 seconds did
a disk system relying on just an elevator get anything
close to decent throughput.
This paper convinced me that doing just elevator sorting
is never enough ;)
> The problem is that read-ahead (seems to) go completely havoc when
> read()'s are issued in many threads at the same time.
In that case, probably the readahead windows are too large
or the cache memory used for these readahead pages is too
small.
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
regards,
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