Re: [RFC/RFT PATCH v3] sched: automated per tty task groups

From: Vivek Goyal
Date: Tue Nov 16 2010 - 14:42:01 EST


On Tue, Nov 16, 2010 at 08:25:27PM +0100, Peter Zijlstra wrote:
> On Tue, 2010-11-16 at 14:22 -0500, Vivek Goyal wrote:
> > In this thread there are already mentions of extending it to block
> > controller also which now supports the upper limit.
> >
> > Secondly I am assuming at some point of time, cpu controller will also
> > support throttling (including SCHED_OTHER class).
>
> Possibly, but in both cases its voluntary -- that is, unless explicitly
> configured a cgroup can use as much as possible. These auto groups will
> use that.
>
> If you want more control, create your own cgroup so you can poke at the
> parameters at will.

I can create my own cgroups and control these. But one would like to
control these hidden groups also. For example, in a clustered environment
one might not want allow more than certain IOPS from machine X. In such
scenario one would like to see all the groups and possibly put the limit.

Now one can argue that thse groups are under root and put overall limit
on root and these groups get automatically controlled. But controllers
like block and memory also support flat mode where all the groups are
at same level.

pivot
/ | \
root g2 g3

Here g2 and g3 are hidden auto groups and because it is flat configuration
putting limit on root will not help and one can not limit g2 and g3 and
one can not control total amount of IO from the system.

Now one can say use hierarchy and not flat setup. I am writting patches
to enable hierarchy but that is disabled by default as flat setup came
first and also there are concerns of accounting overhead etc.

So point being that these autogroups being hidden is a concern. Can we
do something so that these groups show up in cgroup hierarchy and are
then user controllable.

Thanks
Vivek
--
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/