Re: [locks] 6d390e4b5d: will-it-scale.per_process_ops -96.6% regression

NeilBrown
2020-03-10T21:22:02Z

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]