On 23 January 2014 19:31, Frederic Weisbecker <fweis...@gmail.com> wrote: > Ok, so it is fine to migrate the latter kind I guess?
Unless somebody has abused the API and used bound workqueues where he should have used unbound ones. > I haven't checked the details but then this quiesce option would involve > a dependency on cpuset for any workload involving workqueues affinity. I'm > not sure we really want this. Besides, workqueues have an existing sysfs > interface > that can be easily extended. > > Now indeed we may also want to enforce some policy to make sure that further > created and queued workqueues are affine to a specific subset of CPUs. And > then > cpuset sounds like a good idea :) Exactly. Cpuset would be more useful here. Probably we can keep both cpusets and sysfs interface of workqueues.. I will try to add this option under cpuset which will initially move timers and workqueues away from the cpuset in question. -- 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/
