Re: [ckrm-tech] [RFC] [PATCH 00/12] CKRM after a major overhaul

Shailabh Nagar
2006-04-24T20:42:50Z

Hirokazu Takahashi wrote:

>
>
>>i/o controller: This controller is not ported to the framework posted,
>>but can be taken for a prototype version. New version would be simpler
>>though.
>>
>>
>
>I think controlling I/O bandwidth is right way to go.
>
>
Thanks. Obviously we agree heartily :-)

>However, I think you need to change the design of the controller a bit.
>A lot of I/O requests processes issue will be handled by other contexts.
>There are AIO, journaling, pdflush and vmscan, which some kernel threads
>treat instead of the processes.
>
>The current design looks not to care about this.
>
>
Yes. The current design, which builds directly on top of the CFQ
scheduler, does not attempt to treat kernel
threads specially in order to account the I/O they're doing on behalf of
others properly. This was mainly because
of the desire to keep the controller simple.

I suspect pdflush and vmscan I/O is never going to be properly
attributable and journaling may be possible but
unlikely to be worth it given the risks of throttling it ? AIO is
likely to be something we can address if there is
consensus that one is willing to pay the price of tracking the source
through the I/O submission layers.

I suppose this would be a good time to dust off the I/O controller and
post it so discussions can become more
concrete.

But as always, changes in the design and implementation are always
welcome....

Regards,
Shailabh

>Thanks,
>Hirokazu Takahashi.
>
>