[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <875zfbvrbm.fsf@notabene.neil.brown.name>
Date: Wed, 11 Mar 2020 08:21:49 +1100
From: NeilBrown <neilb@...e.de>
To: Jeff Layton <jlayton@...nel.org>, yangerkun <yangerkun@...wei.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Cc: kernel test robot <rong.a.chen@...el.com>,
LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org,
Bruce Fields <bfields@...ldses.org>,
Al Viro <viro@...iv.linux.org.uk>
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
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
Powered by blists - more mailing lists