Re: Sched_autogroup and niced processes

[Ingo Molnar <mingo@elte.hu>]

* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> On Fri, 2011-05-13 at 11:29 +0200, Ingo Molnar wrote:
> > * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > 
> > > On Fri, 2011-05-13 at 11:05 +0200, Ingo Molnar wrote:
> > > > Could we somehow automate this:
> > > > 
> > > >   > echo 19 > /proc/'pid of seti@home'/autogroup
> > > > 
> > > > and split off nice 19 tasks into separate groups and lower the group's 
> > > > priority? 
> > > 
> > > Well I guess you can stack on all kinds of heuristics, do we want to?
> > 
> > Well have you seen my non-heuristic suggestion:
> > 
> >  | Another thing we could do is to lower the priority of a cgroup if it *only* 
> >  | runs reniced tasks. I.e. track the 'maximum priority' of cgroups and 
> >  | propagate that to their weight.
> >  |
> >  | This way renicing within cgroups will be more powerful and people do not have 
> >  | to muck with cgroup details.
> > 
> > A cgroup assuming the highest priority of all tasks it contains is a pretty 
> > natural definition and extension of priorities and also solves this usecase.
> 
> Well, that a heuristic in my book, and it totally destroys the independence 
> of groups from tasks (resulting in O(n) task nice behaviour).
> 
> I really don't see why we should do this, if people don't want what it does, 
> don't use it. If you want something else, you can do all these things from 
> userspace to suit your exact needs.
> 
> We have enough knobs to set things up as you want them, no need to make 
> things more complicated.

Ok, i guess you are right, propagating priorities does break the clean 
hieararchy we have currently.

Still, the other important problem is that we still seem to have a bug, even 
with the cgroup set to low prio seti@home is sucking up CPU resources ...

Thanks,

	Ingo