Re: [ckrm-tech] [RFC 3/5] sched: Add CPU rate hard caps

[Srivatsa Vaddagiri <vatsa@in.ibm.com>]

On Fri, Jun 02, 2006 at 04:47:19PM +0200, Mike Galbraith wrote:
> > > Consider make.  A cap on make itself isn't meaningful, and _any_ per
> > > task cap you put on it with the intent of managing the aggregate, is
> > > defeated by the argument -j.  Per task caps require omniscience to be
> > > effective in managing processes.  That's a pretty severe limitation.
> > 
> > These caps aren't trying to control aggregates but with suitable 
> > software they can be used to control aggregates.
> 
> How?  How would you deal with the make example with per task caps.

If we add some grouping mechanism for tasks (CKRM or PAGG), then this 
could be handled easily by adjusting the per-task limit based on the
number of tasks in the group? For example, when make is started, it
could be the only task in the group, with a per-task (& group_limit) of 50%. 
As it forks more tasks, the per-task limit of everyone in the group is 
adjusted (lazily perhaps at the next scheduler tick time) based on the 
group_limit/num_of_tasks_in_group. 

This would still require a resource control daemon to adjust the
per-task limit of tasks within a group (if some task in underutilizing
its bandwidth for example).


-- 
Regards,
vatsa