Re: [RFC] Block IO Controller V3

[Gui Jianfeng]

Vivek Goyal wrote:
> On Mon, Nov 30, 2009 at 03:29:52PM +0800, Gui Jianfeng wrote:
>> Vivek Goyal wrote:
>>> Hi Jens,
>>>
>>> This is V3 of the Block IO controller patches on top of "for-2.6.33" branch
>>> of block tree.
>>>
>> ...
>>
>> Hi Vivek,
>>
>> If an idle task is running group A and a normal task is running in group B, these
>> two group have the same weight, I think IO Controller should isolate group A and
>> group B, these two group should get 50% of the IO bw for each, right? But for this case,
>> we don't see any isolation, instead, group B monopolizes almost all IO BW. I guess
>> the major reason is idle cfqq is only allowed to dispatch one request and get expired.
>> I think in order to get better isolation, we shouldn't expire the idle cfqq immediately
>> if this idle queue is the only one this its group. The following patch enable idling
>> for idle queue and prevent expiring it immediately after dispatch one request if it's 
>> the only one in group. This patch is working for V3, hasn't tested on V4 yet.
>>
> 
> Hi Gui,
> 
> Thanks for the patch. I have intentionally kept idle queue make dispatch
> one request at a time system wide irrespective of group.
> 
> What's the use case scenario of enforcing idle dispatch more based on
> group weight. If somebody has marked a queue idle, he is not expecting
> much of that queue anyway.

  IMHO, If somebody decide to put an idle task into a group, i think he
  should know what will happen(isolation thing).

> 
> Now one can argue that for better isolation, don't make idle class system
> wide and an idle task should get more disk time if there are no other
> queues with-in group.
> 
> So for the time being I will leave as it is. We can fix this once somebody
> needs stronger isolation even for idle tasks.
> 

So, maybe we can rely on group_isolation tunable, when group_isolation == 1, 
we provide isolation for idle queues.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/