Messages in this thread | | | Date | Thu, 8 Mar 2012 16:51:18 -0800 | From | Tejun Heo <> | Subject | Re: workqueues and percpu (was: [PATCH] dm: remake of the verity target) |
| |
Adding a bit..
On Thu, Mar 08, 2012 at 04:33:09PM -0800, Tejun Heo wrote: > ISTR there was something already broken about having specific CPU > assumption w/ workqueue even before cmwq when using queue_work_on() > unless it was explicitly synchronizing using cpu hotplug callback. > Hmmm... what was it... I think it was that there was no protection > against queueing on workqueue on dead CPU and workqueue was flushed > only once during cpu shutdown meaning that queue_work_on() or > requeueing work items could end up queued on a workqueue of a dead > CPU.
I think the crux of the problem is that we didn't have the interface to indicate the intention of workqueue users. Per-cpu workqueues were the normal ones and the per-cpuness is used both as optimization (local queueing is much cheaper and a work item is likely to access the same stuff its queuer was accessing) and pinning. Single-threaded workqueues were used for both non-reentrancy and resource optimization.
For the short term, the easiest fix would be adding flush_work_sync() from cpu hotplug callback for the pinned ones. For the longer term, I think the most natural fix would be making work items queued with explicit queue_work_on() handled differently and adding debug code to enforce it.
Thanks.
-- tejun
| |