[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220830114712.GT6159@paulmck-ThinkPad-P17-Gen-1>
Date: Tue, 30 Aug 2022 04:47:12 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: Joel Fernandes <joel@...lfernandes.org>,
linux-kernel@...r.kernel.org,
Rushikesh S Kadam <rushikesh.s.kadam@...el.com>,
"Uladzislau Rezki (Sony)" <urezki@...il.com>,
Neeraj upadhyay <neeraj.iitr10@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
rcu <rcu@...r.kernel.org>, vineeth@...byteword.org
Subject: Re: [PATCH v4 00/14] Implement call_rcu_lazy() and miscellaneous
fixes
On Tue, Aug 30, 2022 at 12:50:02PM +0200, Frederic Weisbecker wrote:
> On Mon, Aug 29, 2022 at 01:31:31PM -0700, Paul E. McKenney wrote:
[ . . . ]
> > Another test would be to look at which callbacks are being invoked
> > on each grace period. We have to have a substantial number of grace
> > periods having all lazy callbacks before call_rcu_lazy() has any chance
> > of helping. This would need to happen on a server platform because
> > Android and ChromeOS data might or might not carry over.
>
> Also that yes.
What would be the best way to collect that data?
Please keep in mind that unless/until we have some clear empirical
indication that call_rcu_lazy() really would help the world of systems
running without rcu_nocbs, moving the call_rcu_lazy() implementation
from the bypass list to cblist does nothing but increase risk to system
that get no benef from call_rcu_lazy().
Thanx, Paul
Powered by blists - more mailing lists