Hello, again. On Mon, Dec 24, 2012 at 10:33:34AM -0800, Tejun Heo wrote: > I don't think we have cases where this actually matters but it could > be that we can add work_pending() tests to queue_work_on(). I *think* > that shouldn't break work scheduling semantics. Not completely sure > tho. Need to think about it more.
I was confused a bit there. We can't. Nothing guarantees that the queuer sees the cleared PENDING before the work item starts execution, and I think ipc memory hotplug could also be broken from that. It's highly unlikely to actually happen and there may be external locking which prevents the race from actually happening, but there's nothing synchronizing queueing and the execution of the work item. Looking at that part of code only, it's possible that it fails to queue the work item after a memory hotplug event even though the previous queueing already started execution and processed a couple notifiers. And you can see why you don't want this type of tricky micro optimizations unless it's absolutely necessary and carefully considered. Cold paths get much less attention and testing. Adding micro optimizations to them is just a bad idea. 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/
