Re: [PATCH 0/4] sched: Add CPU rate caps

[Balbir Singh]

Peter Williams wrote:
> Andrew Morton wrote:
>
> > On Sun, 18 Jun 2006 18:26:38 +1000
> > Peter Williams <pwil3058@xxxxxxxxxxxxxx> wrote:
> >
> > People are going to want to extend this to capping a *group* of tasks, 
> > with
> > some yet-to-be-determined means of tying those tasks together.  How well
> > suited is this code to that extension?
>
>
> Quite good.  It can be used from outside the scheduler to impose caps on 
> arbitrary groups of tasks.  Were the PAGG interface available I could 
> knock up a module to demonstrate this.  When/if the "task watchers" 
> patch is included I will try and implement a higher level mechanism 
> using that.  The general technique is to get an estimate of the 
> "effective number" of tasks in the group (similar to load) and give each 
> task in the group a cap which is the group's cap divided by the 
> effective number of tasks (or the group cap whichever is smaller -- i.e. 
> the effective number of tasks could be less than one).
> )


There is one possible issue with this approach. Lets assume that we desire
a cap of 10 for a set of two tasks. As discussed earlier, each task
would get a limit of 5% if they are equally busy.

Lets call the group as G1 and the tasks as T1 and T2.

If we have another group called G2 with tasks T3, T4 and T5 and a soft
cap of 90. Then each of T3, T4 and T5 would get a soft cap of
30% (assuming that they are equally busy). Now if T5 stops using its limit
for a while let say its cpu utilization is 10% - how do we divide the saved
20% between T1, T2, T3 and T4.

In a group scenario, the balance 20% should be shared between T3 and T4.

Also mathematically

A group is a superset of task

It is hard to implement things for a task and make it work for groups,
but if we had something for groups, we could easily adapt it to tasks
by making each group equal to a task



> Doing it inside the scheduler is also doable but would have some locking 
> issues.  The run queue lock could no longer be used to protect the data 
> as there's no guarantee that all the tasks in the group are associated 
> with the same queue.
>
> > If the task can exceed its cap without impacting any other tasks (ie: 
> > there
> > is spare idle capacity), what happens?
>
>
> That's the difference between soft and hard caps.  If it's a soft cap 
> then the task is allowed to exceed it if there's spare capacity.  If 
> it's a hard cap it's not.

By how much is the task allowed to exceed if there is spare capacity?
Will the spare capacity allocation require resetting of caps to implement
the new caps?

> >  I trust that spare capacity gets
> > used?  (Is this termed "work conserving"?)
>
>
> Soft caps, yes.  Hard caps, no.

--
	Cheers,
	Balbir Singh,
	Linux Technology Center,
	IBM Software Labs
-
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/