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

[Peter Williams]

Srivatsa Vaddagiri wrote:
> On Sun, Jun 18, 2006 at 08:25:02PM +1000, Peter Williams 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" 
>
> For demonstration purpose, maybe you could use tsk->uid to group tasks and 
> and see how capping at group level works out? Basically cap the per-user cpu
> usage.

I was thinking of doing the group of tasks that represent a process's 
threads as a first example as that will be more useful to ordinary users 
as well as demonstrating the technique.

> > 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).
>
> For "effective number" do you include only runnable tasks?

It would be roughly equivalent to a smoothed smoothed estimate of the 
number of runnable tasks in the group.

> As and when
> this number changes, you would need to go and change the per-task cap of
> all tasks in the group. Any idea what the cost of that operation would
> be? Or do you intend to do it lazily to amortize some of that cost?

Yes.  It would be some form of periodical sampling mechanism.  It could 
be done from user space or from a module.

The costs can also be reduced by realizing that it is only necessary to 
do anything at all if the number of tasks in the group is greater than 
the group's cap.  I.e. if a group has a cap of 3000 but only two tasks 
there is no way the group can exceed its cap so that group can be ignored.

> > 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.


--
Peter Williams                                   pwil3058@xxxxxxxxxxxxxx

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
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/