[lkml]   [2020]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [locks] 6d390e4b5d: will-it-scale.per_process_ops -96.6% regression
On Wed, Mar 11, 2020 at 3:22 PM NeilBrown <> wrote:
> We can combine the two ideas - move the list_del_init() later, and still
> protect it with the wq locks. This avoids holding the lock across the
> callback, but provides clear atomicity guarantees.

Ugfh. Honestly, this is disgusting.

Now you re-take the same lock in immediate succession for the
non-callback case. It's just hidden.

And it's not like the list_del_init() _needs_ the lock (it's not
currently called with the lock held).

So that "hold the lock over list_del_init()" seems to be horrendously
bogus. It's only done as a serialization thing for that optimistic

And that optimistic case doesn't even *want* that kind of
serialization. It really just wants a "I'm done" flag.

So no. Don't do this. It's mis-using the lock in several ways.


 \ /
  Last update: 2020-03-12 01:39    [W:0.172 / U:2.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site