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

[Vivek Goyal]

On Tue, Nov 16, 2010 at 09:06:26PM -0500, Ted Ts'o wrote:
> On Wed, Nov 17, 2010 at 01:21:59AM +0100, Lennart Poettering wrote:
> > > I think you really want to make this be something which the
> > > application can specify by default that they should start in their own
> > > cgroup.  One idea might be to it to the applications menu entry:
> > > 
> > > http://standards.freedesktop.org/desktop-entry-spec/latest/
> > > 
> > > ... so there would be a new key value pair, "start_in_cgroup", that
> > > would allow the user to start an application in their own cgroup.  It
> > > would be up to the desktop launcher to honor that if it was present.
> > 
> > This is pretty much in line with what I want to do, except I want
> > opt-out, not opt-in behaviour here.
> 
> That works for me.  One suggestion is that in addition to "opt-out",
> it should be also possible for an application launcher file to specify
> a specific cgroup name that should be used.  That would allow multiple
> applications in a group to assigned to the same cgroup.

Being able to specify cgroup name/path is a good idea. That way one can
make use of cgroup hierarchy also.

Thinking more about opt-in vs opt-out issue. Generally cgroups provide
some kind of isolation between application groups and in the process
can be somewhat expensive. More memory allocation, more accounting overhead
and for CFQ block controller it can also mean additional idling and can result
in overall reduced throughput.

Keeping that in mind, is it really a good idea to launch each application
in a separate group. Will it be better to let user decide if the
application should be launched in a separate cgroup? 

The flip side is that how many people will really know about the functionality
and will really launch application in a separate group. And may be it is
a good idea to put everybody in a seprate cgroup by default even it means
some cost so that if a application starts consuming too much of resources
(make -j64), then its impact on rest of the groups can be contained.

I really don't have strong inclination for one over other. Just thinking
loud...

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/