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 - 07:36:50 EST

Andrea Arcangeli wrote:

>On Mon, Feb 10, 2003 at 11:11:01PM +1100, Nick Piggin wrote:
>>I don't understand it at all. I mean there is no other IO going
>Unfortunately I can't help you understand it, but this is what I found
>with my pratical experience, I found it the first time in my alpha years
>ago when I increased the sym to 512k in early 2.4 then since it could
>break stuff we added the max_sectors again in 2.4. But of course if you
>don't fix readahead there's no way reads can take advantage of these
>lowlevel fixes. I thought I fixed readahead too but I felt it got backed
>out and when I noticed I resurrected it in my tree (see the name of the
>patch ;)
Fair enough. I accept it is important. Still think its odd ;)


>>It would be easy to anticipate or not based on hints. We could
>>anticipate sync writes if we wanted, lower expire time for sync
>>writes, increase it for async reads. It is really not very
>>complex (although the code needs tidying up).
>this is not the way I thought at it. I'm interested to give an hint
>only to know for sure which are the intermediate sync dependent reads
>(the obvious example is when doing the get_block and walking the
>3 level of inode indirect metadata blocks with big files, or while
>walking the balanced tree in reiserfs), and I'm not interested at all
>about writes. And I would just set an higher timeout when a read that I
>know for sure (thanks to the hint) is "intermdiate" is completed. We can
>use high timeouts there because we know they won't trigger 90% of the
>time, a new dependent read will be always submitted first.
This is a lot of nitty gritty stuff. It will all help, especially
in corner cases. Luckily it seems you don't need such
infrastructure to demonstrate most anticipatory scheduler gains.

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:27 EST