On Thu, Apr 03, 2014 at 10:58:05AM -0400, Tejun Heo wrote: > Hello, Frederic. > > On Thu, Apr 03, 2014 at 04:42:55PM +0200, Frederic Weisbecker wrote: > > > I'm not really sure this is the good approach. I think I wrote this > > > way back but wouldn't it make more sense to allow userland to restrict > > > the cpus which are allowed to all unbound cpus. As currently > > > implemented, setting WQ_SYSFS to give userland more control would > > > escape that workqueue from this global mask as a side effect, which is > > > a surprising behavior and doesn't make much sense to me. > > > > I just considered that anon workqueues shouldn't be that different from > > another WQ_SYSFS workqueue. This way we don't have suprising side effect. > > Touching a WQ_SYSFS doesn't impact anon workqueues, and touching anon > > workqueues > > doesn't impact WQ_SYSFS workqueues. > > I really think it'd be a lot better to perceive the default attributes > to be layered below explicit WQ_SYSFS attributes; otherwise, we have > two disjoint sets and the workqueues would jump between the two > depending on WQ_SYSFS. A system tool which wants to configure all > workqueues would have to scan and manipulate all of them not knowing > what specific one's requirements are and tools which want to configure > specific ones likely won't know what the overruling condition is and > violate the global contraints. It'd be clearer to have the layering > pre-defined and enforced.
Ok, works for me. > > > In fact this is simply the current way we do it, just extended. > > Yes, in term of mechanics, it is but I don't think that's what we > want. We want to be able to say "unbound workqueues in general are > confined to these cpus" and it's weird to just provide knobs for wqs > which don't have knobs. Yeah I like the simplicity of that. > > > Yeah I like this. So the right place for this cpumask would be in > > the root of /sys/devices/virtual/workqueue/ , right? > > Yes, I think that'd make more sense. Ok, I'll try this. Thanks! > > 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/