[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8c3ac35d-5056-4f4b-a8c4-ca625fa01b1f@paulmck-laptop>
Date: Fri, 16 Jun 2023 14:26:59 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, kernel-team@...a.com,
rcu@...r.kernel.org, jonathanh@...dia.com, wenst@...omium.org,
angelogioacchino.delregno@...labora.com,
rafael.j.wysocki@...el.com, mirq-linux@...e.qmqm.pl,
dmitry.osipenko@...labora.com, sachinp@...ux.ibm.com,
qiang.zhang1211@...il.com
Subject: Re: [GIT PULL] RCU regression fix for v6.4
On Fri, Jun 16, 2023 at 11:50:31AM -0700, Linus Torvalds wrote:
> On Fri, 16 Jun 2023 at 09:34, Paul E. McKenney <paulmck@...nel.org> wrote:
> >
> > Yes, it would be nice to abstract this somehow in order to hide it in
> > SRCU, but I still don't see a good way of doing this.
>
> Ehh - like we actually do spinlocks in general, perhaps?
>
> Spinlocks always exist. On UP - with no spinlock debugging - it turns
> into a zero-sized data structure, and the spin lock/unlock operations
> are no-ops.
>
> Why don't you just do the exact same thing with the "struct
> srcu_usage". For Tiny SRCU, just make it an empty struct, with an
> empty initializer.
>
> IOW, don't "abstract it out". Abstract it IN. Make tiny-rcu still have
> it, just as a no-op.
>
> Anyway, I've pulled your fix, but maybe the above would have been the
> cleaner solution?
Good point, thank you! I will add the lock to Tiny SRCU, shooting for
the v6.6 merge window.
Thanx, Paul
Powered by blists - more mailing lists