lkml.org 
[lkml]   [2020]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [locks] 6d390e4b5d: will-it-scale.per_process_ops -96.6% regression
On Tue, Mar 10 2020, Jeff Layton wrote:

>> @@ -735,11 +723,13 @@ static void __locks_wake_up_blocks(struct file_lock *blocker)
>>
>> waiter = list_first_entry(&blocker->fl_blocked_requests,
>> struct file_lock, fl_blocked_member);
>> - __locks_delete_block(waiter);
>> + locks_delete_global_blocked(waiter);
>> + waiter->fl_blocker = NULL;
>> if (waiter->fl_lmops && waiter->fl_lmops->lm_notify)
>> waiter->fl_lmops->lm_notify(waiter);
>> else
>> wake_up(&waiter->fl_wait);
>> + list_del_init(&waiter->fl_blocked_member);
>
> Are you sure you don't need a memory barrier here? Could the
> list_del_init be hoisted just above the if condition?
>

A compiler barrier() is probably justified. Memory barriers delay reads
and expedite writes so they cannot be needed.

wake_up(&waiter->fl_wait);
+ /* The list_del_init() must not be visible before the
+ * wake_up completes, the the waiter can then be freed.
+ */
+ barrier();
+ list_del_init(&waiter->fl_blocked_member);

Thanks,
NeilBrown
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2020-03-10 22:22    [W:2.217 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site