[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, 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.



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