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

[Andrea Arcangeli]

On Mon, Feb 10, 2003 at 07:27:51PM +1100, Nick Piggin wrote:
> 
> 
> 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).

the way things works, if you give 8k readahead, you'll end submitting 8k
requests no matter how long you wait and it will kill throughput to 10%
of what was possible to achieve, very especially with scsi, max
coalescing of ide is 64k and btw that is its main weakness IMHO.

It doesn't make any sense to me your claim that you can decrease the
readahead by adding anticipatory scheduling, if you do you'll run
so slow at 8k per request in all common workloads.

> 
> 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
> >
> >
> > 
> >
> 

Andrea