From: Mel Gorman <mgorman@techsingularity.net>
To: Waiman Long <longman@redhat.com>
Cc: Zhenhua Ma <mazhenhua@xiaomi.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Boqun Feng <boqun.feng@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@suse.com>
Subject: Re: Lockups due to "locking/rwsem: Make handoff bit handling more consistent"
Date: Wed, 22 Jun 2022 16:09:44 +0100 [thread overview]
Message-ID: <20220622150944.GG15453@techsingularity.net> (raw)
In-Reply-To: <2c4084e3-9bd0-76ef-a11c-857de96a83e5@redhat.com>
On Tue, Jun 21, 2022 at 09:32:12PM -0400, Waiman Long wrote:
> On 6/20/22 10:09, Mel Gorman wrote:
> > On Fri, Jun 17, 2022 at 10:29:20AM -0400, Waiman Long wrote:
> > > > The C file and shell script to run it are attached.
> > > >
> > > Thanks for the reproducer and I will try to reproduce it locally.
> > >
> > > It is a known issue that I have receive similar report from an Oracle
> > > engineer. That is the reason I posted commit 1ee326196c66 ("locking/rwsem:
> > > Always try to wake waiters in out_nolock path") that was merged in v5.19. I
> > > believe it helps but it may not be able to eliminate all possible race
> > > conditions. To make rwsem behave more like before commit d257cc8cb8d5
> > > ("locking/rwsem: Make handoff bit handling more consistent"), I posted a
> > > follow-up patch
> > >
> > > https://lore.kernel.org/lkml/20220427173124.1428050-1-longman@redhat.com/
> > >
> > > But it hasn't gotten review yet.
> > >
> > FWIW, the patch passed the test case when applied to both 5.18 and
> > 5.19-rc3.
>
> Thanks for running the test. Do you mean that both 5.18 and 5.19-rc3 fail
> the test and they pass only after applying the patch?
>
Yes.
> Anyway, I am not able to reproduce the failure in both 5.18 and 5.19-rc3.
> Perhaps it is due to the difference in the running environment, i.e. gcc,
> glibc, etc. What operating environment (SuSE version) do you use to
> reproduce the failure? I used RHEL8 which is the most convenient one for me.
>
It was reproduced on Leap 15.4 with a 2-socket machine with 40 cores
(SMT-2). The kernel built was based on the distribution config. gcc
version was based on 7.5.0.
> BTW, do you mind if I put down your name with a "Tested-by:" tag to the
> patch?
>
No problem.
--
Mel Gorman
SUSE Labs
prev parent reply other threads:[~2022-06-22 15:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-17 13:43 Lockups due to "locking/rwsem: Make handoff bit handling more consistent" Mel Gorman
2022-06-17 14:29 ` Waiman Long
2022-06-20 14:09 ` Mel Gorman
2022-06-22 1:32 ` Waiman Long
2022-06-22 15:09 ` Mel Gorman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220622150944.GG15453@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=boqun.feng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mazhenhua@xiaomi.com \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.