On Thu, Sep 01, 2022 at 05:30:34PM +0200, Frederic Weisbecker wrote: > On Thu, Sep 01, 2022 at 07:41:58AM -0700, Paul E. McKenney wrote: > > On Thu, Sep 01, 2022 at 01:59:10PM +0200, Uladzislau Rezki wrote: > > > On Thu, Sep 01, 2022 at 01:29:47PM +0200, Frederic Weisbecker wrote: > > > > On Tue, Aug 30, 2022 at 06:44:51PM +0200, Uladzislau Rezki wrote: > > > > > Hello, Frederic. > > > > > > > > > > > > > > > > > Although who knows, may be some periodic file operation while idle are specific > > > > > > to Android. I'll try to trace lazy callbacks while idle and the number of grace > > > > > > periods associated. > > > > > > > > > > > > > > > > > Everything related to lazy call-backs is about not waking "nocb" > > > > > kthreads in order to offload one or i should say few callbacks > > > > > because it is more or less useless. Currently if incoming callback > > > > > is the only one, it will kick a GP whereas a GP will kick nocb_kthread > > > > > to offload. > > > > > > > > Not sure this is only about not waking "nocb" kthreads. The grace period > > > > kthread is also awaken in !NOCB and has quite some work to do. And there, > > > > having a server expands the issue because you may have a lot of CPUs's extended > > > > quiescent states to check. > > > > > > > I mean here the following combination: NOCB + call_rcu_lazy() tandem. > > > The !NOCB is not about power save, IMHO. Because it implies callbacks > > > to be processed on CPUs they are landed. > > > > > > In this scenario you can not let the EAS scheduler to find a more > > > efficient CPU for further handling. > > > > Just to follow up, Uladzislau and others did some detailed performance > > analysis of NOCB on Android. Of course, this analysis might or might > > not carry over to servers, but it was pretty detailed. > > Sure I certainly don't deny the benefit on Android and similar workload. > What I'm worried about is that we are making this feature too specialized > when it may deserve to be made more generic. > > I'm not convincing anyone though and I don't have the means to provide > numbers, I would need to produce an actual !NOCB implementation for that. I have not yet given up on thinking about what measurements I could take that would be convincing within Meta. Maybe some idea will present itself on the plane. If nothing else, exploratory measurements with rcutop. > So I'm not entirely comfortable but I'm going to review the current patchset > anyway and once it lands -rcu I'll try to hack a quick !NOCB implementation > for measurements purpose. That sounds like a very good approach! Thanx, Paul
