Re: [PATCH cgroup/for-3.11 1/3] cgroup: mark "tasks" cgroup file as insane

[Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

Hello, Glauber.

On Fri, Jun 07, 2013 at 02:32:34PM +0400, Glauber Costa wrote:
> It seems quite valid for me to split priority threads in a process and
> give them a 80 % timeslice guarantee, while leaving only 20 % for
> low-prio threads (for instance).
> 
> In general, I don't think that it would hurt to allow separation at
> thread level *for the leaves*, specifically at the cpu related controllers.

But if you look at the larger picture, it actually is deterimental,
because allowing different threads of the same process almost implies
that the program binary itself would be involved in interacting with -
accessing and tuning - cgroups.  Back to sysctl analogy, it's one
thing to expose them to base system tools which are tightly coupled
with the kernel so that they can configure it, but allowing lay
programs to embed sysctl tuning inside their binaries is a completely
different thing and something which must not happen.

While not strictly designated explicitly, things exposed from the
kernel have differing levels of exposedness and we do definitely want
to avoid exposing too much implementation details for the sake of both
the kernel and userland.  Such levels are in some cases determined as
the use cases develop.  If you ask me, cgroup is a good example of
things going horribly wrong.

So, yeah, while I agree that per-thread usages could make sense for
scheduler related controllers, I'd very much like to avoid that if at
all possible.  It's not a good road to be on.

Thanks.

-- 
tejun