Re: [PATCH 25/25] ipc: don't use [delayed_]work_pending()

From: Tejun Heo
Date: Mon Dec 24 2012 - 13:33:30 EST


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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/