From: Frederic Weisbecker <frederic@kernel.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Rik van Riel <riel@surriel.com>,
Matthew Wilcox <willy@infradead.org>,
Qi Zheng <zhengqi.arch@bytedance.com>,
Peter Zijlstra <peterz@infradead.org>,
David Hildenbrand <david@redhat.com>,
kernel test robot <oliver.sang@intel.com>,
oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
David Rientjes <rientjes@google.com>,
Hugh Dickins <hughd@google.com>, Jann Horn <jannh@google.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Mel Gorman <mgorman@suse.de>, Muchun Song <muchun.song@linux.dev>,
Peter Xu <peterx@redhat.com>, Will Deacon <will@kernel.org>,
Zach O'Keefe <zokeefe@google.com>,
Dan Carpenter <dan.carpenter@linaro.org>,
Neeraj Upadhyay <neeraj.upadhyay@kernel.org>
Subject: Re: [linus:master] [x86] 4817f70c25: stress-ng.mmapaddr.ops_per_sec 63.0% regression
Date: Wed, 29 Jan 2025 17:53:43 +0100 [thread overview]
Message-ID: <Z5pdF1w9Lcwpdixp@localhost.localdomain> (raw)
In-Reply-To: <05da0ae9-073e-4578-b65c-f837c28eead8@paulmck-laptop>
Le Wed, Jan 29, 2025 at 08:36:12AM -0800, Paul E. McKenney a écrit :
> On Wed, Jan 29, 2025 at 11:14:29AM -0500, Rik van Riel wrote:
> > On Wed, 2025-01-29 at 16:12 +0000, Matthew Wilcox wrote:
> > > On Wed, Jan 29, 2025 at 10:59:20AM -0500, Rik van Riel wrote:
> > > > Below is a tentative fix for the issue. It is kind of a big hammer,
> > > > and maybe the RCU people have a better idea on how to solve this
> > > > problem, but it may be worth giving this a try to see if it helps
> > > > with the regression you identified.
> > >
> > > Perhaps better to do:
> > >
> > > +++ b/mm/page_alloc.c
> > > @@ -97,8 +97,8 @@ static DEFINE_MUTEX(pcp_batch_high_lock);
> > > * On SMP, spin_trylock is sufficient protection.
> > > * On PREEMPT_RT, spin_trylock is equivalent on both SMP and UP.
> > > */
> > > -#define pcp_trylock_prepare(flags) do { } while (0)
> > > -#define pcp_trylock_finish(flag) do { } while (0)
> > > +#define pcp_trylock_prepare(flags) rcu_read_lock()
> > > +#define pcp_trylock_finish(flag) rcu_reada_unlock()
> > > #else
> > >
> > > /* UP spin_trylock always succeeds so disable IRQs to prevent re-
> > > entrancy. */
> > >
> > > with appropriate comment changes
> > >
> > Agreed. Assuming this change even works :)
> >
> > Paul, does this look like it could do the trick,
> > or do we need something else to make RCU freeing
> > happy again?
>
> I don't claim to fully understand the issue, but this would prevent
> any RCU grace periods starting subsequently from completing. It would
> not prevent RCU callbacks from being invoked for RCU grace periods that
> started earlier.
>
> So it won't prevent RCU callbacks from being invoked.
>
> It *will* ensure that only a finite number of RCU callbacks get invoked.
> For some perhaps rather large value of "finite".
>
> Does that help, or is more required?
I don't fully understand the issue either but would spin_lock_bh() help?
Thanks.
next prev parent reply other threads:[~2025-01-29 16:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-28 9:57 [linus:master] [x86] 4817f70c25: stress-ng.mmapaddr.ops_per_sec 63.0% regression kernel test robot
2025-01-28 10:05 ` David Hildenbrand
2025-01-28 11:31 ` Peter Zijlstra
2025-01-28 11:39 ` David Hildenbrand
2025-01-28 13:28 ` Peter Zijlstra
2025-01-28 13:42 ` David Hildenbrand
2025-01-28 15:59 ` Qi Zheng
2025-01-28 17:06 ` Qi Zheng
2025-01-28 17:51 ` Qi Zheng
2025-01-28 18:35 ` Rik van Riel
2025-01-29 8:14 ` Qi Zheng
2025-01-29 15:23 ` Rik van Riel
2025-01-29 15:59 ` Rik van Riel
2025-01-29 16:12 ` Matthew Wilcox
2025-01-29 16:14 ` Rik van Riel
2025-01-29 16:36 ` Paul E. McKenney
2025-01-29 16:53 ` Rik van Riel
2025-01-29 17:33 ` Qi Zheng
2025-01-29 17:53 ` Qi Zheng
2025-01-29 19:19 ` Paul E. McKenney
2025-01-31 21:11 ` Rik van Riel
2025-02-01 3:44 ` Qi Zheng
2025-01-29 16:53 ` Frederic Weisbecker [this message]
2025-01-29 16:57 ` Rik van Riel
2025-01-29 17:23 ` Frederic Weisbecker
2025-01-29 17:28 ` Paul E. McKenney
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=Z5pdF1w9Lcwpdixp@localhost.localdomain \
--to=frederic@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=dan.carpenter@linaro.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lorenzo.stoakes@oracle.com \
--cc=luto@kernel.org \
--cc=mgorman@suse.de \
--cc=muchun.song@linux.dev \
--cc=neeraj.upadhyay@kernel.org \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=paulmck@kernel.org \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=rientjes@google.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=zhengqi.arch@bytedance.com \
--cc=zokeefe@google.com \
/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.