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

From: Nick Piggin <piggin@cyberone.com.au>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Jakob Oestergaard <jakob@unthought.net>,
	Andrew Morton <akpm@digeo.com>,
	David Lang <david.lang@digitalinsight.com>,
	riel@conectiva.com.br, ckolivas@yahoo.com.au,
	linux-kernel@vger.kernel.org, axboe@suse.de
Subject: Re: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest]
Date: Mon, 10 Feb 2003 20:18:42 +1100	[thread overview]
Message-ID: <3E476E72.4060900@cyberone.com.au> (raw)
In-Reply-To: 20030210090248.GP31401@dualathlon.random

Andrea Arcangeli wrote:

>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.
>
I mean you kill throughput by submitting non linear requests. OK
with such small requests you probably would lose some throughtput
due to much greater ratio of overheads to work done, but in general
we are talking about disk head positioning. 10 1MB requests should
be much quicker than 1000 10K requests, for disk performance.