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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/