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

From: Nick Piggin (
Date: Mon Feb 10 2003 - 03:27:51 EST

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

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Feb 15 2003 - 22:00:26 EST