Re: Sched_autogroup and niced processes

From: Ingo Molnar
Date: Fri May 13 2011 - 06:04:26 EST



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

> On Fri, 2011-05-13 at 11:29 +0200, Ingo Molnar wrote:
> > * Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> 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
--
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/