Hey, Peter. On Fri, Jun 05, 2015 at 06:22:16PM +0200, Peter Zijlstra wrote: > There's a lot more problems with workqueues: > > - they're not regular tasks and all the task controls don't work on > them. This means all things scheduler, like cpu-affinity, nice, and > RT/deadline scheduling policies. Instead there is some half baked > secondary interface for some of these. Because there's a pool of them and the workers come and go dynamically. There's no way around it. The attributes just have to be per-pool. > But this also very much includes things like cgroups, which brings me > to the second point. > > - its oblivious to cgroups (as it is to RT priority for example) both > leading to priority inversion. A work enqueued from a deep/limited > cgroup does not inherit the task's cgroup. Instead this work is ran > from the root cgroup. > > This breaks cgroup isolation, more significantly so when a large part > of the actual work is done from workqueues (as some workloads end up > being). Instead of being able to control the work, it all ends up in > the root cgroup outside of control. cgroup support will surely be added but I'm not sure we can or should do inheritance automatically. Using a different API doesn't solve the problem automatically either. A lot of kthreads are shared system-wide after all. We'll need an abstraction layer to deal with that no matter where we do it. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
