Mike Galbraith <bitbuc...@online.de> writes: > On Sun, 2014-02-16 at 08:41 -0800, Paul E. McKenney wrote: > >> So if there is NO_HZ_FULL, you have no objection to binding workqueues to >> the timekeeping CPUs, but that you would also like some form of automatic >> binding in the !NO_HZ_FULL case. Of course, if a common mechanism could >> serve both cases, that would be good. And yes, cpusets are frowned upon >> for some workloads. > > I'm not _objecting_, I'm not driving, Frederic's doing that ;-) > > That said, isolation seems to be turning into a property of nohz mode, > but as I see it, nohz_full is an extension to generic isolation. > >> So maybe start with Kevin's patch, but augment with something else for >> the !NO_HZ_FULL case? > > Sure (hm, does it work without workqueue.disable_numa ?).
[ /me returns from vacation ] Yes, since it happens for every alloc_workqueue_attrs() > It just seems to me that tying it to sched domain construction would be > a better fit. That way, it doesn't matter what your isolation requiring > load is, whether you run a gaggle of realtime tasks or one HPC task your > business, the generic requirement is isolation, not tick mode. For one > HPC task per core, you want no tick, if you're running all SCHED_FIFO, > maybe you want that too, depends on the impact of nohz_full mode. All > sensitive loads want the isolation, but they may not like the price. > > I personally like the cpuset way. Being able to partition boxen on the > fly makes them very flexible. In a perfect world, you'd be able to > quiesce and configure offloading and nohz_full on the fly too, and not > end up with some hodgepodge like this needs boot option foo, that > happens invisibly because of config option bar, the other thing you have > to do manually.. and you get to eat 937 kthreads and tons of overhead on > all CPUs if you want the ability to _maybe_ run a critical task or two. Yeah, my patch only addresses the nohz_full case, but since there doesn't seem to be any general agreemenet about the generic case, it seems that exposing all unbound workqueues via WQ_SYSFS is the way to go. Mike, looks like you may have started on that. Did it get any further? Kevin -- 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/
