Re: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest]

[Nick Piggin <piggin@cyberone.com.au>]

Andrea Arcangeli wrote:

>On Mon, Feb 10, 2003 at 01:07:25PM +0300, Hans Reiser wrote:
>
>>Andrew Morton wrote:
>>
>>
>>>Large directories tend to be spread all around the disk anyway.  And I've
>>>never explicitly tested for any problems which the loss of readahead might
>>>have caused ext2.  Nor have I tested inode table readahead.  Guess I 
>>>should.
>>>
>>>
>>>-
>>>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/
>>>
>>>
>>>
>>>
>>>
>>readahead seems to be less effective for non-sequential objects.  Or at 
>>
>
>yes, this is why I said readahead matters mostly to generate the bigdma
>commands, so if the object is sequential it will be served by the
>lowlevel with a single dma using SG. this is also why when I moved the
>high dma limit of scsi to 512k (from 128k IIRC) I got such a relevant
>throughput improvement. Also watch the read speed in my tree compared to
>2.4 and 2.5 in bigbox.html from Randy (bonnie shows it well).
>
...AND readahead matters mostly to disk head scheduling when there
is other IO competing with the streaming read...

A big throughput improvement would have seen would be all to do with
better disk head scheduling due to the larger request sizes, yeah?
And this would probably be to do with the elevator accounting being
based on requests and/or seeks. You shouldn't notice much difference
with the elevator stuff in Andrew's mm patches.

I don't know too much about SCSI stuff, but if driver / wire / device
overheads were that much higher at 128K compared to 512K I would
think something is broken or maybe optimised badly.

Nick