[lkml]   [2012]   [Dec]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 25/25] ipc: don't use [delayed_]work_pending()
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.



 \ /
  Last update: 2012-12-24 19:41    [W:0.089 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site