On Mon, Aug 29, 2022 at 4:31 PM Paul E. McKenney <paulmck@xxxxxxxxxx> 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
