[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEXW_YRay19Dw5W1QVjshoi5b7DWhFb=pzSdF9hs-asH3do2cA@mail.gmail.com>
Date: Mon, 29 Aug 2022 16:54:59 -0400
From: Joel Fernandes <joel@...lfernandes.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: Frederic Weisbecker <frederic@...nel.org>,
LKML <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 Pillai <vineeth@...byteword.org>
Subject: Re: [PATCH v4 00/14] Implement call_rcu_lazy() and miscellaneous fixes
On Mon, Aug 29, 2022 at 4:31 PM Paul E. McKenney <paulmck@...nel.org> wrote:
[...]
> > > > 3) We are mixing up two very different things in a single list of callbacks:
> > > > lazy callbacks and flooding callbacks, as a result we are adding lots of
> > > > off-topic corner cases all around:
> > > > * a seperate lazy len field to struct rcu_cblist whose purpose is much more
> > > > general than just bypass/lazy
> > > > * "lazy" specialized parameters to general purpose cblist management
> > > > functions
> > >
> > > I think just 1 or 2 functions have a new lazy param. It didn't seem too
> > > intrusive to me.
> >
> > What bothers me is that struct cblist has a general purpose and we are adding a field
> > and a parameter that is relevant to only one specialized user.
>
> This does sound like a bad idea, now that you mention it. Joel, if
> this is still in place, can it be moved near the rcu_data structure's
> bypass-related fields?
Yes, I can certainly do that! Consider it gone *poof* from the
rcu_cblist structure, and moved into the rcu_data.
>
> And by the way, thank you for reviewing this patch series!
And my thanks as well! I am deeply appreciative of y'alls work and
participation.
> > > > So here is a proposal: how about forgetting NOCB for now and instead add a new
> > > > RCU_LAZY_TAIL segment in the struct rcu_segcblist right after RCU_NEXT_TAIL?
> > > > Then ignore that segment until some timer expiry has been met or the CPU is
> > > > known to be busy? Probably some tiny bits need to be tweaked in segcblist
> > > > management functions but probably not that much. And also make sure that entrain()
> > > > queues to RCU_LAZY_TAIL.
> > > >
> > > > Then the only difference in the case of NOCB is that we add a new timer to the
> > > > nocb group leader instead of a local timer in !NOCB.
> > >
> > > It sounds reasonable, but I'll go with Paul on the usecase argument - who would
> > > actually care about lazy CBs outside of power, and would those guys ever use
> > > !NO_CB if they cared about power / battery?
> >
> > _Everybody_ cares about power. Those who don't yet will very soon ;-)
>
> Apparently not enough to use CONFIG_RCU_FAST_NO_HZ. Though to be fair,
> that option had its own performance issues. And it would not reduce
> grace periods anywhere near as much as call_rcu_lazy(). But the problem
> was that last I checked on server workloads, the callbacks were mostly
> those that could not reasonably be lazy.
I see! FWIW, lazy-RCU does not have a lot of benefit on busy systems
in our testing (because other non-lazy RCU CBs keep churning grace
period cycles). So for servers that are mostly busy, the power benefit
may not be that much IMHO.
Thanks,
- Joel
Powered by blists - more mailing lists