Hello, Borislav. On Sat, Dec 22, 2012 at 12:09:29PM +0100, Borislav Petkov wrote: > Now you say those paths are not fast paths, but the reverse of > this optimization is also true: what happens if people start using > schedule_work() in fast paths without checking whether work is pending? > A useless IRQ disable + locked operation + IRQ enable.
That's a really strange argument. If we extend from that, we have to optimize cold paths to prevent fast paths copy from them, which sounds really silly to me. If one looks at something happening in a path as cold as memory hotplug and thinks about optimizing a coupld memory accesses, the person's priorities need serious reconsideration. I think approaches like that are actively harmful. They lead to unnecessary (and thus difficult to comprehend) convolutions which don't really help anything while deteoriorating code base. 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. 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/