2003-05-01 11:39:31

by Ed Tomlinson

[permalink] [raw]
Subject: Re: [BENCHMARK] 2.5.68-mm3 with contest

Andrew Morton wrote:

> Con Kolivas <[email protected]> wrote:
>>
>> All the io-write based loads were affected.
>
> Yup. Mainly because the large queue increases truncate latencies.

Are there loads that do benefit from large queues? If so, does it make
sense to use truncate impact (something like a decaying average of truncate
time per interval) to control the size of the queues on the fly?

Comments
Ed Tomlinson


2003-05-01 18:22:04

by Nick Piggin

[permalink] [raw]
Subject: Re: [BENCHMARK] 2.5.68-mm3 with contest

Ed Tomlinson wrote:

>Andrew Morton wrote:
>
>
>>Con Kolivas <[email protected]> wrote:
>>
>>>All the io-write based loads were affected.
>>>
>>Yup. Mainly because the large queue increases truncate latencies.
>>
>
>Are there loads that do benefit from large queues? If so, does it make
>sense to use truncate impact (something like a decaying average of truncate
>time per interval) to control the size of the queues on the fly?
>
I'll post some more benchmarks, but I have found that loads with
lots of IO streams. Those with more than about 1/2 as many IO streams
as request slots start to show improvements. I don't think changing
the size of the queues on the fly would be any good. They can be
made runtime tunable quite easily now, which is a good bad solution.