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

[Shailabh Nagar]

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.
>  

-
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/