On Wed, 2015-07-22 at 11:25 -0400, Tejun Heo wrote: > Hello, > > On Wed, Jul 22, 2015 at 05:19:00PM +0200, Mike Galbraith wrote: > > Ew, looking at the numbers, they may prefer to either a) pretend to not > > notice, or b) scurry off to HPC'R'US store if a) won't fly ;-) > > Yeah, there are a lot of them. The sad part is that only very few of > them would actually need local binding for correctness. :(
I'm going to end this thread with an under my breath mutter. Before I do that, note that I went and beat up three different boxen over days before turning trivial little patchlet loose, ie I was quite paranoid despite the below, "No way Jose" was not entirely unexpected. Mutter: WORK_CPU_UNBOUND is about as far from a local execution guarantee as it gets, and not only is it prominently displayed for all to see... /** * queue_work - queue work on a workqueue * @wq: workqueue to use * @work: work to queue * * Returns %false if @work was already on a queue, %true otherwise. * * We queue the work to the CPU on which it was submitted, but if the CPU dies * it can be processed by another CPU. */ static inline bool queue_work(struct workqueue_struct *wq, struct work_struct *work) { return queue_work_on(WORK_CPU_UNBOUND, wq, work); } ...there's nothing ambiguous about that. While it states that we queue locally, it also clearly states that local execution is NOT guaranteed, making assumption thereof a BUG, which in turn makes it seem a bit odd to tie fixing up nohz_full a little to auditing and fixing every booboo ever made (unlikely to ever happen). It would appear that the only way anyone could ever have sanely assume local execution, WORK_CPU_UNBOUND aside, is to have called get_online_cpus() before queueing any work. Mutter expressed, it's not a big hairy deal, anyone using an SMP kernel with an expectation of zero perturbation is doomed to be disappointed anyway, patchlet just reduced noise a bit. -Mike (mutter mutter mutter;) -- 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/