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

[NeilBrown <neilb@suse.de>]

[-- 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 --]