It also seems that you're really looking for limits, not shares. Shares have to apportion 100% amongst the existing classes and thus impose constraints on the number of classes depending on the granularity supported by the controller. Limits don't need to add up to 100 so hundreds of classes could each have a (soft)limit of say 5%. So errant classes/vservers would, under overload, be limited from harming others.
This is precisely what I am looking for. Can you do this "share" based io controller and the "priority class" based io controller in one? Or would they become two different types of mutually exclusive io controllers?
Yes, it should be possible.
Getting limits to work for a larger number of classes would be easier with the current setup.
To get shares to work for a large number of classes would need a little more thought about the changes needed to CFQ. The latter relies on round-robining through queues and we might need to transition to a GPS based sorted queues (like what the CPU controller uses).
Since limits would be the more useful and smaller incremental change, why don't I think about that first ?
-- Shailabh
Meanwhile, could you comment on the stability of the patch ? Do you have problems compiling/running ?
It compiled. Will try to see whether the basic system boots with it.
Marc
------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
