Re: [RFC] Block IO Controller V2 - some results

[Corrado Zoccolo]

Hi Vivek,
On Fri, Nov 20, 2009 at 8:50 PM, Corrado Zoccolo <czoccolo@xxxxxxxxx> wrote:
> On Fri, Nov 20, 2009 at 7:42 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
>>
>> Should we also take into account the "cfqq->dispatched" request in
>> determining whether we should enable idling on deep queue random seeky
>> readers?
>
> Probably, but I think the most important thing is to do some averaging
> or hysteresis, so the completion of a single request doesn't cause the
> switch of a workload.

can you test the new version of the idling patch?
I register the fact that the queue had a large depth in a flag, that
is reset only when the idle times out (so at the end of the burst).
Idling is enabled if that flag is set (and think time is acceptable).
This should fix the switching behaviour you observed.

I decided to not count cfqq->dispatched to determine the depth.
In this way, when all queues in the system are random the idling is
enabled only if the requests queue builds up faster than it can be
consumed.

Thanks,
Corrado

Attachment: 0002-cfq-iosched-idling-on-deep-seeky-sync-queues.patch
Description: Binary data