On Fri, Jun 02, 2006 at 04:23:04AM -0700, Matt Helsley wrote: > There are two problems as I see it: > > 1) If X1 grows to use 35% then X2's usage can't grow back from 15% until > X1 relents. This is seems unpleasantly like cooperative scheduling > within group X because if we take this to its limit X2 gets 0% and X1 > gets 50% -- effectively starving X2. What little I know about nice > suggests this wouldn't really happen. However I think may highlight one > case where fiddling with nice can't effectively control CPU usage.
I would expect task Z to adjust the limits of X1, X2 again when it notices that X2 is "hungry". Until Z gets around to do that, what situation you describe will be true. If Z is configured to run quite frequently (every 5 seconds?) to monitor/adjust limits, then this starvation (of X2) may be avoided for longer periods? > 2) Suppose we add group Y with tasks Y1-YM, Y's CPU usage is limited to > 49%, each task of Y uses its limit of (M/49)% CPU, and the remaining 1% > is left for Z (i.e. the single CPU is being used heavily). Z must use > this 1% to read accounting information and adjust nice values as > described above. If X1 spawns X3 we're likely in trouble -- Z might not > get to run for a while but X3 has inheritted X1's nice value. If we > return to our initial assumption that X1 and X2 are each using their > limit of 25% then X3 will get limited to 25% too. The sum of Xi can now > exceed 50% until Z is scheduled next. This only gets worse if there is > an imbalance between X1 and X2 as described earlier. In that case group > X could use 100% CPU until Z is scheduled! It also probably gets worse > as load increases and the number of scheduling opportunities for Z > decrease. > > > I don't see how task Z could solve the second problem. As with UP, in > SMP I think it depends on when Z (or one Z fixed to each CPU) is > scheduled. Wouldn't it help if Z is made to run with nice -20 (or with RT prio maybe), so that when Z wants to run (every 5 or 10 seconds) it is run immediately? This is assuming that Z can do its job of adjusting limits for all tasks "quickly" (maybe 100-200 ms?). > > I think these are simple scenarios that demonstrate the problem with > splitting resource management into accounting and control with userspace > in between. > > Cheers, > -Matt Helsley -- Regards, vatsa _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
