Messages in this thread |  | | From | NeilBrown <> | Date | Wed, 11 Mar 2020 08:21:49 +1100 | Subject | Re: [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] |  |