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 06:41:14PM +1100, Nick Piggin wrote:
>
>>Andrea Arcangeli wrote:
>>
>>
>>>On Mon, Feb 10, 2003 at 03:58:26PM +1100, Nick Piggin wrote:
>>>
>>>>Remember that readahead gets scaled down quickly if it isn't
>>>>getting hits. It is also likely to be sequential and in the
>>>>track buffer, so it is a small cost.
>>>>
>>>>Huge readahead is a problem however anticipatory scheduling
>>>>will hopefully allow good throughput for multiple read streams
>>>>without requiring much readahead.
>>>>
What I mean by this is: if we have >1 sequential readers (eg. ftp
server), lets say 30MB/s disk, 4ms avg seek+settle+blah time,
submitting reads in say 128KB chunks alternating between streams
will cut throughput in half... At 1MB readahead we're at 89%
throughput. At 2MB, 94%

With anticipatory scheduling, we can give each stream say 100ms
so thats 96% with, say... 8K readahead if you like. (Yes, I am
aware that CPU/PCI/IDE efficiency also mandates a larger request
size).

Anyway that is the theory. It remains to be seen if we can make
it work.

>>>>
>>>>
>>>the main purpose of readahead is to generate 512k scsi commands when you
>>>read a file with a 4k user buffer, anticipatory scheduling isn't very
>>>related to readahead.
>>>
>>>
>>You seem to be forgetting things like seek time.
>>
>
>I didn't say it's the only purpose. Of course there's no hope for
>merging in the metadata dependent reads of the fs where anticipatory
>scheduling does its best, and infact they don't even attempt to do any
>readhaead.  BTW, one thing that should definitely do readhaead and it's
>not doing that (at least in 2.4) is the readdir path, again to generate
>big commands, no matter the seeks.  It was lost with the directory in
>pagecache.
>
>Andrea
>
>
>  
>