Hi vatsa, > > To support the limit, surplus CPU is waisted. I don't think > > it is a good design. In other words, if every class is satisfied > > in terms of its CPU guarantee and some classes can consume more, > > surplus CPU should be given to the classes. Therefore, I'm not > > interested in supporting the limit currently. > > Can't you define this limit as "soft" limit? That would address your > concerns?
Sorry, I can't get your point. It is a choice of how to mannage surplus resource. Let's use surplus resource is current choice. As Rajaram's first try, if 20% of share is assigned to kernbench and there is no other CPU hog process in the other class, the rest of share, 80% is surplus. Currently surplus CPU resource is assinged to anyone who can consume CPU more. That is why kernbench can consume whole CPU unless other CPU hog process is running on the other class. It is current choice. There is another choice, which is don't use surplus resource even if someone can consume CPU more. In this choice, kernbench can consume only 20% of CPU and the rest of 80% of CPU is waisted. Given that one of them must be chosen, I do believe the current choice is better. Logically, supporting both guarantee and limit is possible, but it would introduce complexity and overhead, parhaps. I'd rather perfer keeping the CPU controller as simple as possible at least before it is accecpted by the Linux kernel commnunity. Thanks, MAEDA Naoaki ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
