Re: [RFD] CAT user space interface revisited

From: Tejun Heo
Date: Wed Jan 06 2016 - 08:10:26 EST


Hello, Marcelo.

On Wed, Jan 06, 2016 at 10:46:15AM -0200, Marcelo Tosatti wrote:
> Well, i suppose cgroups has facilities to handle this? That is, what is
> required is:

No, it doesn't.

> On task creation, move the new task to a particular cgroup, based on
> some visible characteristic of the task: (process name matching OR explicit
> kernel thread creator specification OR ...).

cgroup's primary goal is resource tracking and control. For userland
processes, following fork / clone is enough; however, for a lot of
kthread tasks, task isn't even the right unit. e.g. Think of CPU
cycles spent on packet reception, spawning per-cgroup kthreads to
handle packet rx separately isn't a realistic option. The granularity
needs to be higher. Except for a handful of cases, this pattern
holds. Another example is IO resources spent during journal write.
Most of in-kernel resource tracking can't be split per-kthread.

While assigning kthreads to specific cgroups can be useful for a few
specific use cases, in terms of in-kernel resource tracking, it's more
of a distraction.

Please stop using cgroup for random task grouping. Supporting the
level of flexibility to support arbitrary grouping gets in the way of
implementing proper resource control. You won't be happy because
cgroup's rules get in the way and cgroup won't be happy because your
random stuff gets in the way of proper resource control.

Thomas's proposal obviously works better for the task at hand. Maybe
there's something which can be extracted out of cgroup and shared for
task group tracking, if nothing else, hooks and synchronization, but
please don't tack it on top of cgroup when it doesn't really fit the
hierarchical resource distribution model.

Thanks.

--
tejun
--
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/