On Tue, 2006-02-21 at 15:59 +0900, MAEDA Naoaki wrote:
> 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?
>
I think Vatsa is differentiating between "hard limit"(class will not get
any resource and the surplus resources will be wasted) and "soft
limit" (class can get resource over its soft limit if there is surplus).
IMO, advantage of using "soft limit" is that it can be used as a
relative priority when surplus resources are to be allocated to classes.
For example, consider 3 classes, which are CPU hogs, with soft limits
Class A 20%
Class B 25%
Class C 30%
and when all of them reached their soft limit(total usage 75%), the
remaining 25% can be divided between them proportional to their soft
limit. i.e
Class A would get => 25 * 20/(20+25+30) ==> 6.66%
Class B would get => 25 * 25/(20+25+30) ==> 8.33%
Class C would get => 25 * 30/(20+25+30) ==> 10%
> 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.
Ideally i would like to see both guarantee and limit supported, as the
main objective of CKRM is empowering the sysadmin with knobs to control
how the system resources are utilized.
If limit is not a good option (in the current design), then we should
have a "priority", that would decide which class would get preference if
there are surplus resources.
Priority can be strict (class with priority 2 will get surplus resource
only if the class with priority 1 doesn't need it) or relative (class
with priority 10 will get 10 times of the available surplus resource
than a class with priority 1)
>
> 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.
I totally agree with the last part.
>
> 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
--
----------------------------------------------------------------------
Chandra Seetharaman | Be careful what you choose....
- [EMAIL PROTECTED] | .......you may get it.
----------------------------------------------------------------------
-------------------------------------------------------
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
