| Message ID | 20220819204857.3066329-1-joel@joelfernandes.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Implement call_rcu_lazy() and miscellaneous fixes | expand |
On Fri, Aug 19, 2022 at 08:48:43PM +0000, Joel Fernandes (Google) wrote: > Refresh tested on real ChromeOS userspace and hardware, passes boot time tests > and rcuscale tests. > > Fixes on top of v3: > - Fix boot issues due to a race in the lazy RCU logic which caused a missed > wakeup of the RCU GP thread, causing synchronize_rcu() to stall. > - Fixed trace_rcu_callback tracepoint > > I tested power previously [1], I am in the process of testing power again but I > wanted share my latest code as others who are testing power as well could use > the above fixes. Your patch is very likely to be _generally_ useful and therefore, the more I look into this, the more I wonder if it is a good idea to rely on bypass at all, let alone NOCB. Of course in the long term the goal is to have bypass working without NOCB but why even bothering implementing it for nocb in the first place? Several highlights: 1) NOCB is most often needed for nohz_full and the latter has terrible power management. The CPU 0 is active all the time there. 2) NOCB without nohz_full has extremely rare usecase (RT niche: https://lore.kernel.org/lkml/CAFzL-7vqTX-y06Kc3HaLqRWAYE0d=ms3TzVtZLn0c6ATrKD+Qw@mail.gmail.com/ ) 2) NOCB implies performance issues. 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 4) This is further complexifying bypass core code, nocb timer management, core nocb group management, all of which being already very complicated. 5) The !NOCB implementation is going to be very different Ok I can admit one counter argument in favour of using NO_CB: -1) The scheduler can benefit from a wake CPU to run the callbacks on behalf of a bunch of idle CPUs, instead of waking up that bunch of CPUs. But still we are dealing with callbacks that can actually wait... 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. Now of course I'm certainly overlooking obvious things as always :) Thanks.
Hi Frederick, On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: > On Fri, Aug 19, 2022 at 08:48:43PM +0000, Joel Fernandes (Google) wrote: >> Refresh tested on real ChromeOS userspace and hardware, passes boot time tests >> and rcuscale tests. >> >> Fixes on top of v3: >> - Fix boot issues due to a race in the lazy RCU logic which caused a missed >> wakeup of the RCU GP thread, causing synchronize_rcu() to stall. >> - Fixed trace_rcu_callback tracepoint >> >> I tested power previously [1], I am in the process of testing power again but I >> wanted share my latest code as others who are testing power as well could use >> the above fixes. > > Your patch is very likely to be _generally_ useful and therefore, > the more I look into this, the more I wonder if it is a good idea to rely on > bypass at all, let alone NOCB. Of course in the long term the goal is to have > bypass working without NOCB but why even bothering implementing it for nocb > in the first place? This was discussed with Paul [1]. Quoting: ---- Joel: >> Also, does doing so not prevent usage of lazy CBs on systems without >> NOCB? So if we want to future-proof this, I guess that might not be a >> good decision. > Paul: > True enough, but would this future actually arrive? After all, if > someone cared enough about energy efficiency to use call_rcu_lazy(), > why wouldn't they also offload callbacks? Joel: I am not sure, but I also don't mind making it depend on NOCB for now (see below). [1] https://www.spinics.net/lists/rcu/msg07908.html ---- While I agree with you that perhaps making it more generic is better, this did take a significant amount of time, testing and corner case hunting to come up with, and v5 is also in the works so I'd appreciate if we can do it the bypass-way and optimize later. Arguably the bypass way is quite simple and allows us to leverage its effects of rcu_barrier and such. And the API will not change. > Several highlights: > > 1) NOCB is most often needed for nohz_full and the latter has terrible power > management. The CPU 0 is active all the time there. I see. We don't use nohz_full much. NOCB itself gives good power improvement. > 2) NOCB without nohz_full has extremely rare usecase (RT niche: > https://lore.kernel.org/lkml/CAFzL-7vqTX-y06Kc3HaLqRWAYE0d=ms3TzVtZLn0c6ATrKD+Qw@mail.gmail.com/ > ) Really? Android has been using it for a long time. It seems to be quite popular in the battery-powered space. > 2) NOCB implies performance issues. Which kinds of? There is slightly worse boot times, but I'm guessing that's do with the extra scheduling overhead of the extra threads which is usually not a problem except that RCU is used in the critical path of boot up (on ChromeOS). > 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. > 4) This is further complexifying bypass core code, nocb timer management, core > nocb group management, all of which being already very complicated. True, I agree, a few more cases to handle for sure, but I think I got them all now (hopefully). > 5) The !NOCB implementation is going to be very different > > Ok I can admit one counter argument in favour of using NO_CB: > > -1) The scheduler can benefit from a wake CPU to run the callbacks on behalf of a bunch > of idle CPUs, instead of waking up that bunch of CPUs. But still we are dealing > with callbacks that can actually wait... Yeah that's huge. Significant amount of power improvement seems to come from idle CPUs not being disturbed and their corresponding timer ticks turned off for longer periods. That's experimentally confirmed (NO_CB giving significant power improvement on battery-power systems as compared to !NO_CB). > > 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? Thanks, - Joel
On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > Hi Frederick, > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: > > On Fri, Aug 19, 2022 at 08:48:43PM +0000, Joel Fernandes (Google) wrote: > >> Refresh tested on real ChromeOS userspace and hardware, passes boot time tests > >> and rcuscale tests. > >> > >> Fixes on top of v3: > >> - Fix boot issues due to a race in the lazy RCU logic which caused a missed > >> wakeup of the RCU GP thread, causing synchronize_rcu() to stall. > >> - Fixed trace_rcu_callback tracepoint > >> > >> I tested power previously [1], I am in the process of testing power again but I > >> wanted share my latest code as others who are testing power as well could use > >> the above fixes. > > > > Your patch is very likely to be _generally_ useful and therefore, > > the more I look into this, the more I wonder if it is a good idea to rely on > > bypass at all, let alone NOCB. Of course in the long term the goal is to have > > bypass working without NOCB but why even bothering implementing it for nocb > > in the first place? > > This was discussed with Paul [1]. Quoting: > > ---- > Joel: > >> Also, does doing so not prevent usage of lazy CBs on systems without > >> NOCB? So if we want to future-proof this, I guess that might not be a > >> good decision. > > > Paul: > > True enough, but would this future actually arrive? After all, if > > someone cared enough about energy efficiency to use call_rcu_lazy(), > > why wouldn't they also offload callbacks? > > Joel: I am not sure, but I also don't mind making it depend on NOCB for now > (see below). > > [1] https://www.spinics.net/lists/rcu/msg07908.html > ---- > > While I agree with you that perhaps making it more generic is better, this did > take a significant amount of time, testing and corner case hunting to come up > with, and v5 is also in the works so I'd appreciate if we can do it the > bypass-way and optimize later. Arguably the bypass way is quite simple and > allows us to leverage its effects of rcu_barrier and such. And the API will not > change. Keep in mind that if we later need to rewrite the whole in order to have a generic approach, this will take even more time in the long run. > > 2) NOCB without nohz_full has extremely rare usecase (RT niche: > > https://lore.kernel.org/lkml/CAFzL-7vqTX-y06Kc3HaLqRWAYE0d=ms3TzVtZLn0c6ATrKD+Qw@mail.gmail.com/ > > ) > > Really? Android has been using it for a long time. It seems to be quite popular > in the battery-powered space. It's really sad that this is the first time I hear about that. I've been working on this code for years now without this usecase in mind. And yet it's fundamental. I asked several times around about other usecases of rcu_nocbs than nohz_full= and nobody reported that. I can hardly even google a significant link between power saving and rcu_nocbs= If this is really used that way for a long time then it's a cruel disconnection between users and developers. > > 2) NOCB implies performance issues. > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > with the extra scheduling overhead of the extra threads which is usually not a > problem except that RCU is used in the critical path of boot up (on ChromeOS). I never measured it myself but executing callbacks on another CPUs, with context switches and locking can only involve significant performance issues if callbacks are frequent. So it's a tradeoff between power and performance. > > > 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. > > 4) This is further complexifying bypass core code, nocb timer management, core > > nocb group management, all of which being already very complicated. > > True, I agree, a few more cases to handle for sure, but I think I got them all > now (hopefully). Now I'm worried about maintainability. Hence why I'd rather see a generic code for them all if possible. > > 5) The !NOCB implementation is going to be very different > > > > Ok I can admit one counter argument in favour of using NO_CB: > > > > -1) The scheduler can benefit from a wake CPU to run the callbacks on behalf of a bunch > > of idle CPUs, instead of waking up that bunch of CPUs. But still we are dealing > > with callbacks that can actually wait... > > Yeah that's huge. Significant amount of power improvement seems to come from > idle CPUs not being disturbed and their corresponding timer ticks turned off for > longer periods. That's experimentally confirmed (NO_CB giving significant power > improvement on battery-power systems as compared to !NO_CB). It's a good news to hear that nocbs is used way beyond its initial purpose. But still very sad to hear about that several years late. > > 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 ;-) And given the numbers you provided with your measurements, I bet this will be significant with !NOCB as well. This is not only delaying callbacks execution, this also reduces the frequency of grace periods, and that impact should be quite visible. Note I'm not stricly opposed to the current approach. But I can't say I'm comfortable with it. Can we do a simple test? Would it be possible to affine every rcuo%c/%d kthread to the corresponding CPU%d? For example affine rcuop/1 to CPU 1, rcuop/2 to CPU2, etc... And then relaunch your measurements on top of that? The point is that having the callback kthreads affined to their corresponding CPUs should elude the power saving advantages of rcu_nocbs=, back to roughly a !NOCB behaviour powerwise (except we have context switches). If you find good numbers with this setup then you'll find good numbers with !NOCB. Thanks.
On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > Hi Frederick, > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: > > On Fri, Aug 19, 2022 at 08:48:43PM +0000, Joel Fernandes (Google) wrote: > >> Refresh tested on real ChromeOS userspace and hardware, passes boot time tests > >> and rcuscale tests. > >> > >> Fixes on top of v3: > >> - Fix boot issues due to a race in the lazy RCU logic which caused a missed > >> wakeup of the RCU GP thread, causing synchronize_rcu() to stall. > >> - Fixed trace_rcu_callback tracepoint > >> > >> I tested power previously [1], I am in the process of testing power again but I > >> wanted share my latest code as others who are testing power as well could use > >> the above fixes. > > > > Your patch is very likely to be _generally_ useful and therefore, > > the more I look into this, the more I wonder if it is a good idea to rely on > > bypass at all, let alone NOCB. Of course in the long term the goal is to have > > bypass working without NOCB but why even bothering implementing it for nocb > > in the first place? > > This was discussed with Paul [1]. Quoting: > > ---- > Joel: > >> Also, does doing so not prevent usage of lazy CBs on systems without > >> NOCB? So if we want to future-proof this, I guess that might not be a > >> good decision. > > > Paul: > > True enough, but would this future actually arrive? After all, if > > someone cared enough about energy efficiency to use call_rcu_lazy(), > > why wouldn't they also offload callbacks? > > Joel: I am not sure, but I also don't mind making it depend on NOCB for now > (see below). > > [1] https://www.spinics.net/lists/rcu/msg07908.html > ---- > > While I agree with you that perhaps making it more generic is better, this did > take a significant amount of time, testing and corner case hunting to come up > with, and v5 is also in the works so I'd appreciate if we can do it the > bypass-way and optimize later. Arguably the bypass way is quite simple and > allows us to leverage its effects of rcu_barrier and such. And the API will not > change. Just confirming this conversation, on the hopefully unlikely off-chance that there is any doubt. ;-) That said, if there is some compelling use case that is not addressed by rcu_nocbs, keeping in mind that these can now be made dynamic, then some adjustment will of course be needed. > > Several highlights: > > > > 1) NOCB is most often needed for nohz_full and the latter has terrible power > > management. The CPU 0 is active all the time there. > > I see. We don't use nohz_full much. NOCB itself gives good power improvement. > > > 2) NOCB without nohz_full has extremely rare usecase (RT niche: > > https://lore.kernel.org/lkml/CAFzL-7vqTX-y06Kc3HaLqRWAYE0d=ms3TzVtZLn0c6ATrKD+Qw@mail.gmail.com/ > > ) > > Really? Android has been using it for a long time. It seems to be quite popular > in the battery-powered space. > > > 2) NOCB implies performance issues. > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > with the extra scheduling overhead of the extra threads which is usually not a > problem except that RCU is used in the critical path of boot up (on ChromeOS). Back in 2010, Rik van Riel reported significant slowdowns for some types of Java workloads, but for normal servers, not Android or ChromeOS. I have no idea whether similar slowdowns exist today. But if there is no performance advantage to non-offloaded callbacks, we should first make offloading the default, and if there are no complaints after a few years, remove the non-offloaded case completely. My guess is that at the very least, scheduler corner cases will force us to keep non-offloaded callbacks, but you never know. In any case, a wakeup is considerably more expensive than a non-atomic OR of a bit in a per-CPU variable, so there is some chance that offloading causes some important workloads considerable performance degradation. > > 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. It has been getting simpler! ;-) I bet that the lazy_len field can be a boolean and independent of ->cblist, and that doing that would simplify things at least a little bit. But, yes, an all-lazy indicator of some sort would still need to exist. > > 4) This is further complexifying bypass core code, nocb timer management, core > > nocb group management, all of which being already very complicated. > > True, I agree, a few more cases to handle for sure, but I think I got them all > now (hopefully). If we do need lazy callbacks on non-offloaded CPUs, there will need to be changes to both the bypass logic (possibly just those changes that Joel already has, but Murphy might disagree) and to the ->cblist logic. At the very least, the wakeup logic would need adjustment from current -rcu and there would still need to be some way of tracking whether or not all the callbacks in the bypass list are lazy. > > 5) The !NOCB implementation is going to be very different > > > > Ok I can admit one counter argument in favour of using NO_CB: > > > > -1) The scheduler can benefit from a wake CPU to run the callbacks on behalf of a bunch > > of idle CPUs, instead of waking up that bunch of CPUs. But still we are dealing > > with callbacks that can actually wait... You lost me on this one. Having a callback invoked on a non-idle CPU should save significant power without significant delay in callback invocation. What am I missing here? > Yeah that's huge. Significant amount of power improvement seems to come from > idle CPUs not being disturbed and their corresponding timer ticks turned off for > longer periods. That's experimentally confirmed (NO_CB giving significant power > improvement on battery-power systems as compared to !NO_CB). > > > 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 is certainly good to look into alternatives! Especially if this has somehow broken (de)offloading. (Not seeing it in my testing, but then again, I have not yet tested this series all that much.) How does the separate RCU_LAZY_TAIL segment help? I would think that you would instead want an all-lazy flag on each of the existing RCU_NEXT_READY_TAIL and RCU_NEXT_TAIL segments. After all, if there is even one non-lazy callback in either segment, we need the corresponding grace period to run sooner rather than later. And if we are running a given grace period anyway, it costs little to handle the lazy callbacks while we are at it. Or is there a use case where it helps a lot to defer lazy callbacks that could have been handled by a grace period that needed to happen anyway, due to the presence of non-lazy callbacks? I am having a hard time coming up with one, but perhaps that is a failure of imagination on my part. There would still need to be changes to the bypass code because NOCB is what gets both Android and ChromeOS big power savings. And yes, no matter what, rcu_barrier_entrain() needs to motivate any lazy callbacks. Currently, this falls out from the flushing of the bypass. Presumably, offloading and deoffloading could also take advantage of bypass flushing. And I have no idea whether it would make sense for the NOCB and !NOCB case to share a laziness-motivation timer. > 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? And if they are not using NOCB, does call_rcu_lazy() actually help? But again, if call_rcu_lazy() needs to handle the !NOCB case, then it needs to handle the !NOCB case. However, given ChromeOS and Android, we know that it call_rcu_lazy() needs to handle the NOCB case regardless. Thanx, Paul
On Mon, Aug 29, 2022 at 09:46:22PM +0200, Frederic Weisbecker wrote: > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > > Hi Frederick, > > > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: > > > On Fri, Aug 19, 2022 at 08:48:43PM +0000, Joel Fernandes (Google) wrote: > > >> Refresh tested on real ChromeOS userspace and hardware, passes boot time tests > > >> and rcuscale tests. > > >> > > >> Fixes on top of v3: > > >> - Fix boot issues due to a race in the lazy RCU logic which caused a missed > > >> wakeup of the RCU GP thread, causing synchronize_rcu() to stall. > > >> - Fixed trace_rcu_callback tracepoint > > >> > > >> I tested power previously [1], I am in the process of testing power again but I > > >> wanted share my latest code as others who are testing power as well could use > > >> the above fixes. > > > > > > Your patch is very likely to be _generally_ useful and therefore, > > > the more I look into this, the more I wonder if it is a good idea to rely on > > > bypass at all, let alone NOCB. Of course in the long term the goal is to have > > > bypass working without NOCB but why even bothering implementing it for nocb > > > in the first place? > > > > This was discussed with Paul [1]. Quoting: > > > > ---- > > Joel: > > >> Also, does doing so not prevent usage of lazy CBs on systems without > > >> NOCB? So if we want to future-proof this, I guess that might not be a > > >> good decision. > > > > > Paul: > > > True enough, but would this future actually arrive? After all, if > > > someone cared enough about energy efficiency to use call_rcu_lazy(), > > > why wouldn't they also offload callbacks? > > > > Joel: I am not sure, but I also don't mind making it depend on NOCB for now > > (see below). > > > > [1] https://www.spinics.net/lists/rcu/msg07908.html > > ---- > > > > While I agree with you that perhaps making it more generic is better, this did > > take a significant amount of time, testing and corner case hunting to come up > > with, and v5 is also in the works so I'd appreciate if we can do it the > > bypass-way and optimize later. Arguably the bypass way is quite simple and > > allows us to leverage its effects of rcu_barrier and such. And the API will not > > change. > > Keep in mind that if we later need to rewrite the whole in order to have a > generic approach, this will take even more time in the long run. > > > > 2) NOCB without nohz_full has extremely rare usecase (RT niche: > > > https://lore.kernel.org/lkml/CAFzL-7vqTX-y06Kc3HaLqRWAYE0d=ms3TzVtZLn0c6ATrKD+Qw@mail.gmail.com/ > > > ) > > > > Really? Android has been using it for a long time. It seems to be quite popular > > in the battery-powered space. > > It's really sad that this is the first time I hear about that. I've been working > on this code for years now without this usecase in mind. And yet it's fundamental. > > I asked several times around about other usecases of rcu_nocbs than nohz_full= > and nobody reported that. I can hardly even google a significant link > between power saving and rcu_nocbs= > > If this is really used that way for a long time then it's a cruel disconnection > between users and developers. Knowing me, you probably asked about rcu_nocbs and I probably thought you were asking about nohz_full. :-/ > > > 2) NOCB implies performance issues. > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > > with the extra scheduling overhead of the extra threads which is usually not a > > problem except that RCU is used in the critical path of boot up (on ChromeOS). > > I never measured it myself but executing callbacks on another CPUs, with > context switches and locking can only involve significant performance issues if callbacks > are frequent. So it's a tradeoff between power and performance. It has indeed been a problem for some workloads in the past. But I don't know of any recent measurements. And NOCB has gotten at least somewhat faster over the years. > > > 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? And by the way, thank you for reviewing this patch series! > > > 4) This is further complexifying bypass core code, nocb timer management, core > > > nocb group management, all of which being already very complicated. > > > > True, I agree, a few more cases to handle for sure, but I think I got them all > > now (hopefully). > > Now I'm worried about maintainability. Hence why I'd rather see a generic code > for them all if possible. Let's see what Joel's v5 looks like. > > > 5) The !NOCB implementation is going to be very different > > > > > > Ok I can admit one counter argument in favour of using NO_CB: > > > > > > -1) The scheduler can benefit from a wake CPU to run the callbacks on behalf of a bunch > > > of idle CPUs, instead of waking up that bunch of CPUs. But still we are dealing > > > with callbacks that can actually wait... > > > > Yeah that's huge. Significant amount of power improvement seems to come from > > idle CPUs not being disturbed and their corresponding timer ticks turned off for > > longer periods. That's experimentally confirmed (NO_CB giving significant power > > improvement on battery-power systems as compared to !NO_CB). > > It's a good news to hear that nocbs is used way beyond its initial purpose. > But still very sad to hear about that several years late. It came as a bit of a surprise to me as well, but was why I felt comfortable removing CONFIG_RCU_FAST_NO_HZ. If I remember correctly, the Android power-aware-scheduler folks first tried it out. > > > 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. > And given the numbers you provided with your measurements, I bet this will > be significant with !NOCB as well. This is not only delaying callbacks execution, > this also reduces the frequency of grace periods, and that impact should be > quite visible. > > Note I'm not stricly opposed to the current approach. But I can't say I'm > comfortable with it. > > Can we do a simple test? Would it be possible to affine every rcuo%c/%d kthread > to the corresponding CPU%d? For example affine rcuop/1 to CPU 1, rcuop/2 to > CPU2, etc... And then relaunch your measurements on top of that? > > The point is that having the callback kthreads affined to their corresponding > CPUs should elude the power saving advantages of rcu_nocbs=, back to roughly > a !NOCB behaviour powerwise (except we have context switches). If you find good > numbers with this setup then you'll find good numbers with !NOCB. 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. Thanx, Paul
On Mon, Aug 29, 2022 at 3:46 PM Frederic Weisbecker <frederic@kernel.org> wrote: > > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > > Hi Frederick, > > > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: > > > On Fri, Aug 19, 2022 at 08:48:43PM +0000, Joel Fernandes (Google) wrote: > > >> Refresh tested on real ChromeOS userspace and hardware, passes boot time tests > > >> and rcuscale tests. > > >> > > >> Fixes on top of v3: > > >> - Fix boot issues due to a race in the lazy RCU logic which caused a missed > > >> wakeup of the RCU GP thread, causing synchronize_rcu() to stall. > > >> - Fixed trace_rcu_callback tracepoint > > >> > > >> I tested power previously [1], I am in the process of testing power again but I > > >> wanted share my latest code as others who are testing power as well could use > > >> the above fixes. > > > > > > Your patch is very likely to be _generally_ useful and therefore, > > > the more I look into this, the more I wonder if it is a good idea to rely on > > > bypass at all, let alone NOCB. Of course in the long term the goal is to have > > > bypass working without NOCB but why even bothering implementing it for nocb > > > in the first place? > > > > This was discussed with Paul [1]. Quoting: > > > > ---- > > Joel: > > >> Also, does doing so not prevent usage of lazy CBs on systems without > > >> NOCB? So if we want to future-proof this, I guess that might not be a > > >> good decision. > > > > > Paul: > > > True enough, but would this future actually arrive? After all, if > > > someone cared enough about energy efficiency to use call_rcu_lazy(), > > > why wouldn't they also offload callbacks? > > > > Joel: I am not sure, but I also don't mind making it depend on NOCB for now > > (see below). > > > > [1] https://www.spinics.net/lists/rcu/msg07908.html > > ---- > > > > While I agree with you that perhaps making it more generic is better, this did > > take a significant amount of time, testing and corner case hunting to come up > > with, and v5 is also in the works so I'd appreciate if we can do it the > > bypass-way and optimize later. Arguably the bypass way is quite simple and > > allows us to leverage its effects of rcu_barrier and such. And the API will not > > change. > > Keep in mind that if we later need to rewrite the whole in order to have a > generic approach, this will take even more time in the long run. Agreed on that. But the use > > > 2) NOCB without nohz_full has extremely rare usecase (RT niche: > > > https://lore.kernel.org/lkml/CAFzL-7vqTX-y06Kc3HaLqRWAYE0d=ms3TzVtZLn0c6ATrKD+Qw@mail.gmail.com/ > > > ) > > > > Really? Android has been using it for a long time. It seems to be quite popular > > in the battery-powered space. > > It's really sad that this is the first time I hear about that. I've been working > on this code for years now without this usecase in mind. And yet it's fundamental. > > I asked several times around about other usecases of rcu_nocbs than nohz_full= > and nobody reported that. I can hardly even google a significant link > between power saving and rcu_nocbs= > > If this is really used that way for a long time then it's a cruel disconnection > between users and developers. I was not involved with Android or RCU back then. But my guess is I don't think it was enabled with the intent of saving power, it is just that using RCU_NO_CB_CPU has become the way to go to keep dynick-idle CPUs undisturbed: https://paulmck.livejournal.com/66807.html . Paul , +Dietmar Eggemann can probably provide more history. > > > 2) NOCB implies performance issues. > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > > with the extra scheduling overhead of the extra threads which is usually not a > > problem except that RCU is used in the critical path of boot up (on ChromeOS). > > I never measured it myself but executing callbacks on another CPUs, with > context switches and locking can only involve significant performance issues if callbacks > are frequent. So it's a tradeoff between power and performance. In my testing of benchmarks on real systems with 8-16 CPUs, the performance hit is down in the noise. It is possible though that maybe one can write a non-realistic synthetic test to force the performance issues, but I've not seen it in the real world. Maybe on networking-heavy servers with lots of cores, you'll see it but their batteries if any would be pretty big :-). > > > 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. To Paul's point, we can change it to a flag I think. The 3 states are: - no CBs. - All lazy - All non-lazy Or, worse case, we can move the flag to the per-cpu rcu_data structure, I think. Does that alleviate your concern? > > > 4) This is further complexifying bypass core code, nocb timer management, core > > > nocb group management, all of which being already very complicated. > > > > True, I agree, a few more cases to handle for sure, but I think I got them all > > now (hopefully). > > Now I'm worried about maintainability. Hence why I'd rather see a generic code > for them all if possible. Maintainability is a concern for any new code. I rely a lot on testing both synthetic, and real-world. I have spent a lot of time on test code on this. > > > 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 ;-) > > And given the numbers you provided with your measurements, I bet this will > be significant with !NOCB as well. This is not only delaying callbacks execution, > this also reduces the frequency of grace periods, and that impact should be > quite visible. I will defer to Paul on whether the current approach is a viable solution. If it is not, and we are to take a different design route, it would be good to know that so I can cease current efforts and go back to the drawing board. > > Note I'm not stricly opposed to the current approach. But I can't say I'm > comfortable with it. Maybe we can find a way in the code to see what can be changed. One concern you rightly raised is the length variables , but I think that's not a blocker. > Can we do a simple test? Would it be possible to affine every rcuo%c/%d kthread > to the corresponding CPU%d? For example affine rcuop/1 to CPU 1, rcuop/2 to > CPU2, etc... And then relaunch your measurements on top of that? We already did that and it does not help, it makes things worse. The decision of where to run RCU threads is best left to the scheduler (for both performance and power). > The point is that having the callback kthreads affined to their corresponding > CPUs should elude the power saving advantages of rcu_nocbs=, back to roughly > a !NOCB behaviour powerwise (except we have context switches). If you find good > numbers with this setup then you'll find good numbers with !NOCB. You'll be surprised at the results! ;-) The reaction of everyone I know off who has tried this is a pleasant surprise that "the scheduler might actually know what it's doing" ;-) thanks, - Joel
On Mon, Aug 29, 2022 at 04:36:40PM -0400, Joel Fernandes wrote: > On Mon, Aug 29, 2022 at 3:46 PM Frederic Weisbecker <frederic@kernel.org> wrote: > > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: [ . . . ] > > > > 2) NOCB implies performance issues. > > > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > > > with the extra scheduling overhead of the extra threads which is usually not a > > > problem except that RCU is used in the critical path of boot up (on ChromeOS). > > > > I never measured it myself but executing callbacks on another CPUs, with > > context switches and locking can only involve significant performance issues if callbacks > > are frequent. So it's a tradeoff between power and performance. > > In my testing of benchmarks on real systems with 8-16 CPUs, the > performance hit is down in the noise. It is possible though that maybe > one can write a non-realistic synthetic test to force the performance > issues, but I've not seen it in the real world. Maybe on > networking-heavy servers with lots of cores, you'll see it but their > batteries if any would be pretty big :-). To Frederic's point, if you have enough servers, even a 1% decrease in power consumption is a very big deal. ;-) Thanx, Paul
On Mon, Aug 29, 2022 at 4:42 PM Paul E. McKenney <paulmck@kernel.org> wrote: > > On Mon, Aug 29, 2022 at 04:36:40PM -0400, Joel Fernandes wrote: > > On Mon, Aug 29, 2022 at 3:46 PM Frederic Weisbecker <frederic@kernel.org> wrote: > > > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > > > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: > > [ . . . ] > > > > > > 2) NOCB implies performance issues. > > > > > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > > > > with the extra scheduling overhead of the extra threads which is usually not a > > > > problem except that RCU is used in the critical path of boot up (on ChromeOS). > > > > > > I never measured it myself but executing callbacks on another CPUs, with > > > context switches and locking can only involve significant performance issues if callbacks > > > are frequent. So it's a tradeoff between power and performance. > > > > In my testing of benchmarks on real systems with 8-16 CPUs, the > > performance hit is down in the noise. It is possible though that maybe > > one can write a non-realistic synthetic test to force the performance > > issues, but I've not seen it in the real world. Maybe on > > networking-heavy servers with lots of cores, you'll see it but their > > batteries if any would be pretty big :-). > > To Frederic's point, if you have enough servers, even a 1% decrease in > power consumption is a very big deal. ;-) Ah I see Frederick's point now, so basically the claim is that using lazy-RCU on servers might make sense to save power because CONFIG_RCU_NO_CB_CPU may not be an option there (networking throughput and so forth). That's a good point indeed... As you said, let us see v5 and how we want to proceed from there (as it is not too far from posting) . I do appreciate Frederick's review and valid concerns. Thanks, - Joel
On Mon, Aug 29, 2022 at 4:31 PM Paul E. McKenney <paulmck@kernel.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
On Mon, Aug 29, 2022 at 04:36:40PM -0400, Joel Fernandes wrote: > On Mon, Aug 29, 2022 at 3:46 PM Frederic Weisbecker <frederic@kernel.org> wrote: > > > > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > > > Hi Frederick, > > > > > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: > > > > On Fri, Aug 19, 2022 at 08:48:43PM +0000, Joel Fernandes (Google) wrote: > > > >> Refresh tested on real ChromeOS userspace and hardware, passes boot time tests > > > >> and rcuscale tests. > > > >> > > > >> Fixes on top of v3: > > > >> - Fix boot issues due to a race in the lazy RCU logic which caused a missed > > > >> wakeup of the RCU GP thread, causing synchronize_rcu() to stall. > > > >> - Fixed trace_rcu_callback tracepoint > > > >> > > > >> I tested power previously [1], I am in the process of testing power again but I > > > >> wanted share my latest code as others who are testing power as well could use > > > >> the above fixes. > > > > > > > > Your patch is very likely to be _generally_ useful and therefore, > > > > the more I look into this, the more I wonder if it is a good idea to rely on > > > > bypass at all, let alone NOCB. Of course in the long term the goal is to have > > > > bypass working without NOCB but why even bothering implementing it for nocb > > > > in the first place? > > > > > > This was discussed with Paul [1]. Quoting: > > > > > > ---- > > > Joel: > > > >> Also, does doing so not prevent usage of lazy CBs on systems without > > > >> NOCB? So if we want to future-proof this, I guess that might not be a > > > >> good decision. > > > > > > > Paul: > > > > True enough, but would this future actually arrive? After all, if > > > > someone cared enough about energy efficiency to use call_rcu_lazy(), > > > > why wouldn't they also offload callbacks? > > > > > > Joel: I am not sure, but I also don't mind making it depend on NOCB for now > > > (see below). > > > > > > [1] https://www.spinics.net/lists/rcu/msg07908.html > > > ---- > > > > > > While I agree with you that perhaps making it more generic is better, this did > > > take a significant amount of time, testing and corner case hunting to come up > > > with, and v5 is also in the works so I'd appreciate if we can do it the > > > bypass-way and optimize later. Arguably the bypass way is quite simple and > > > allows us to leverage its effects of rcu_barrier and such. And the API will not > > > change. > > > > Keep in mind that if we later need to rewrite the whole in order to have a > > generic approach, this will take even more time in the long run. > > Agreed on that. But the use > > > > > 2) NOCB without nohz_full has extremely rare usecase (RT niche: > > > > https://lore.kernel.org/lkml/CAFzL-7vqTX-y06Kc3HaLqRWAYE0d=ms3TzVtZLn0c6ATrKD+Qw@mail.gmail.com/ > > > > ) > > > > > > Really? Android has been using it for a long time. It seems to be quite popular > > > in the battery-powered space. > > > > It's really sad that this is the first time I hear about that. I've been working > > on this code for years now without this usecase in mind. And yet it's fundamental. > > > > I asked several times around about other usecases of rcu_nocbs than nohz_full= > > and nobody reported that. I can hardly even google a significant link > > between power saving and rcu_nocbs= > > > > If this is really used that way for a long time then it's a cruel disconnection > > between users and developers. > > I was not involved with Android or RCU back then. But my guess is I > don't think it was enabled with the intent of saving power, it is just > that using RCU_NO_CB_CPU has become the way to go to keep dynick-idle > CPUs undisturbed: https://paulmck.livejournal.com/66807.html . Paul , > +Dietmar Eggemann can probably provide more history. Thanks for the pointer! > > > > 2) NOCB implies performance issues. > > > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > > > with the extra scheduling overhead of the extra threads which is usually not a > > > problem except that RCU is used in the critical path of boot up (on ChromeOS). > > > > I never measured it myself but executing callbacks on another CPUs, with > > context switches and locking can only involve significant performance issues if callbacks > > are frequent. So it's a tradeoff between power and performance. > > In my testing of benchmarks on real systems with 8-16 CPUs, the > performance hit is down in the noise. It is possible though that maybe > one can write a non-realistic synthetic test to force the performance > issues, but I've not seen it in the real world. Maybe on > networking-heavy servers with lots of cores, you'll see it but their > batteries if any would be pretty big :-). Yeah I suspect this should have an impact on servers. And even servers may deserve idleness sometimes. > > > > > 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. > > To Paul's point, we can change it to a flag I think. The 3 states are: > - no CBs. > - All lazy > - All non-lazy Yeah that makes sense, should we take the generic direction! > > Or, worse case, we can move the flag to the per-cpu rcu_data > structure, I think. Does that alleviate your concern? > > > > > 4) This is further complexifying bypass core code, nocb timer management, core > > > > nocb group management, all of which being already very complicated. > > > > > > True, I agree, a few more cases to handle for sure, but I think I got them all > > > now (hopefully). > > > > Now I'm worried about maintainability. Hence why I'd rather see a generic code > > for them all if possible. > > Maintainability is a concern for any new code. I rely a lot on testing > both synthetic, and real-world. I have spent a lot of time on test > code on this. And I thank you for that. I've always been terrible at performance/power/latency testing so I'm always relieved when others take over on that :) > > > > > 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 ;-) > > > > And given the numbers you provided with your measurements, I bet this will > > be significant with !NOCB as well. This is not only delaying callbacks execution, > > this also reduces the frequency of grace periods, and that impact should be > > quite visible. > > I will defer to Paul on whether the current approach is a viable > solution. If it is not, and we are to take a different design route, > it would be good to know that so I can cease current efforts and go > back to the drawing board. Ok. > > > > > Note I'm not stricly opposed to the current approach. But I can't say I'm > > comfortable with it. > > Maybe we can find a way in the code to see what can be changed. One > concern you rightly raised is the length variables , but I think > that's not a blocker. That's just a detail indeed. If we proceed with the current NOCB approach I'll give a deeper review. > > > Can we do a simple test? Would it be possible to affine every rcuo%c/%d kthread > > to the corresponding CPU%d? For example affine rcuop/1 to CPU 1, rcuop/2 to > > CPU2, etc... And then relaunch your measurements on top of that? > > We already did that and it does not help, it makes things worse. The > decision of where to run RCU threads is best left to the scheduler > (for both performance and power). That's the point, we want to artificially remove NOCB advantages to get a behaviour close to !NOCB, so that we know if it's worth expanding the patchset to !NOCB. Let me clarify. The point of NOCB, powerwise, is that the RCU kthreads track and execute the callbacks to an optimized selection of CPUs, thanks to the scheduler. And the new lazy flow optimize that further. Now we would like to know if call_rcu_lazy() also works on !NOCB. But we have no way to test that right now because we only have an implemention for NOCB. But if we affine each rcuop/%d to their corresponding CPU%d, we get a behaviour that is close to !NOCB because then the scheduler doesn't help anymore and callbacks are executed locally (the only difference is that we do context switches, locking and and we still have rcuog around but still, that should give a rough idea of what we get with !NOCB). Therefore if you test your measurements again before and after your patchset, both with each rcuop/%d affine to their CPU%d counterpart, you should get a comparison of before VS after your patchset on what would be an implementation on !NOCB. Thanks.
On Mon, Aug 29, 2022 at 12:57:30PM -0700, Paul E. McKenney wrote: > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > > While I agree with you that perhaps making it more generic is better, this did > > take a significant amount of time, testing and corner case hunting to come up > > with, and v5 is also in the works so I'd appreciate if we can do it the > > bypass-way and optimize later. Arguably the bypass way is quite simple and > > allows us to leverage its effects of rcu_barrier and such. And the API will not > > change. > > Just confirming this conversation, on the hopefully unlikely off-chance > that there is any doubt. ;-) > > That said, if there is some compelling use case that is not addressed > by rcu_nocbs, keeping in mind that these can now be made dynamic, then > some adjustment will of course be needed. Right there is that too. > > > > Several highlights: > > > > > > 1) NOCB is most often needed for nohz_full and the latter has terrible power > > > management. The CPU 0 is active all the time there. > > > > I see. We don't use nohz_full much. NOCB itself gives good power improvement. > > > > > 2) NOCB without nohz_full has extremely rare usecase (RT niche: > > > https://lore.kernel.org/lkml/CAFzL-7vqTX-y06Kc3HaLqRWAYE0d=ms3TzVtZLn0c6ATrKD+Qw@mail.gmail.com/ > > > ) > > > > Really? Android has been using it for a long time. It seems to be quite popular > > in the battery-powered space. > > > > > 2) NOCB implies performance issues. > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > > with the extra scheduling overhead of the extra threads which is usually not a > > problem except that RCU is used in the critical path of boot up (on ChromeOS). > > Back in 2010, Rik van Riel reported significant slowdowns for some types > of Java workloads, but for normal servers, not Android or ChromeOS. > I have no idea whether similar slowdowns exist today. But if there is > no performance advantage to non-offloaded callbacks, we should first make > offloading the default, and if there are no complaints after a few years, > remove the non-offloaded case completely. My gut feeling is that this is a bad idea. Yet I have no practical proof :o) > My guess is that at the very least, scheduler corner cases will force > us to keep non-offloaded callbacks, but you never know. In any case, > a wakeup is considerably more expensive than a non-atomic OR of a bit > in a per-CPU variable, so there is some chance that offloading causes > some important workloads considerable performance degradation. Definetly! > > > > 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. > > It has been getting simpler! ;-) > > I bet that the lazy_len field can be a boolean and independent of > ->cblist, and that doing that would simplify things at least a little bit. > But, yes, an all-lazy indicator of some sort would still need to exist. Yeah, I'll check the patch in detail. > > > > 4) This is further complexifying bypass core code, nocb timer management, core > > > nocb group management, all of which being already very complicated. > > > > True, I agree, a few more cases to handle for sure, but I think I got them all > > now (hopefully). > > If we do need lazy callbacks on non-offloaded CPUs, there will need to > be changes to both the bypass logic (possibly just those changes that > Joel already has, but Murphy might disagree) and to the ->cblist logic. > At the very least, the wakeup logic would need adjustment from current > -rcu and there would still need to be some way of tracking whether or > not all the callbacks in the bypass list are lazy. Sure but we can arrange for pushing the complexity in a common place between NOCB and !NOCB. > > > > 5) The !NOCB implementation is going to be very different > > > > > > Ok I can admit one counter argument in favour of using NO_CB: > > > > > > -1) The scheduler can benefit from a wake CPU to run the callbacks on behalf of a bunch > > > of idle CPUs, instead of waking up that bunch of CPUs. But still we are dealing > > > with callbacks that can actually wait... > > You lost me on this one. Having a callback invoked on a non-idle CPU > should save significant power without significant delay in callback > invocation. What am I missing here? The thing is that if the callback can wait, and does actually, then the advantage of call_rcu_lazy() should be visible whether the callbacks are offloaded or not. > > > Yeah that's huge. Significant amount of power improvement seems to come from > > idle CPUs not being disturbed and their corresponding timer ticks turned off for > > longer periods. That's experimentally confirmed (NO_CB giving significant power > > improvement on battery-power systems as compared to !NO_CB). > > > > > 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 is certainly good to look into alternatives! Especially if this has > somehow broken (de)offloading. (Not seeing it in my testing, but then > again, I have not yet tested this series all that much.) > > How does the separate RCU_LAZY_TAIL segment help? I would think > that you would instead want an all-lazy flag on each of the existing > RCU_NEXT_READY_TAIL and RCU_NEXT_TAIL segments. After all, if there is > even one non-lazy callback in either segment, we need the corresponding > grace period to run sooner rather than later. And if we are running a > given grace period anyway, it costs little to handle the lazy callbacks > while we are at it. Good point! That sounds much better. > Or is there a use case where it helps a lot to defer lazy callbacks that > could have been handled by a grace period that needed to happen anyway, > due to the presence of non-lazy callbacks? I am having a hard time coming > up with one, but perhaps that is a failure of imagination on my part. I don't see one right now. > > There would still need to be changes to the bypass code because NOCB is > what gets both Android and ChromeOS big power savings. Actually using the flag on RCU_NEXT_TAIL and RCU_NEXT_READ_TAIL would avoid touching the bypass code. I see a big advantage in that we don't mix up two orthogonal things anymore: flooding callbacks (normal bypass) and callbacks that can actually wait (lazy callbacks), both needing a different treatment. > And yes, no matter what, rcu_barrier_entrain() needs to motivate any lazy > callbacks. Currently, this falls out from the flushing of the bypass. > Presumably, offloading and deoffloading could also take advantage of > bypass flushing. > > And I have no idea whether it would make sense for the NOCB and !NOCB > case to share a laziness-motivation timer. No at least the timer will need to be different. It should integrate into the existing one in NOCB whereas !NOCB should have something more simple. > > > 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? > > And if they are not using NOCB, does call_rcu_lazy() actually help? I suspect yes, due to the frequency of grace periods lowering. > > But again, if call_rcu_lazy() needs to handle the !NOCB case, then it > needs to handle the !NOCB case. However, given ChromeOS and Android, > we know that it call_rcu_lazy() needs to handle the NOCB case regardless. Right. Thanks.
On Mon, Aug 29, 2022 at 01:31:31PM -0700, Paul E. McKenney wrote: > On Mon, Aug 29, 2022 at 09:46:22PM +0200, Frederic Weisbecker wrote: > > It's really sad that this is the first time I hear about that. I've been working > > on this code for years now without this usecase in mind. And yet it's fundamental. > > > > I asked several times around about other usecases of rcu_nocbs than nohz_full= > > and nobody reported that. I can hardly even google a significant link > > between power saving and rcu_nocbs= > > > > If this is really used that way for a long time then it's a cruel disconnection > > between users and developers. > > Knowing me, you probably asked about rcu_nocbs and I probably thought > you were asking about nohz_full. :-/ Can't remember but no big deal, now we know about it and we can move forward with that in mind. > > > > > 2) NOCB implies performance issues. > > > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > > > with the extra scheduling overhead of the extra threads which is usually not a > > > problem except that RCU is used in the critical path of boot up (on ChromeOS). > > > > I never measured it myself but executing callbacks on another CPUs, with > > context switches and locking can only involve significant performance issues if callbacks > > are frequent. So it's a tradeoff between power and performance. > > It has indeed been a problem for some workloads in the past. But I don't > know of any recent measurements. And NOCB has gotten at least somewhat > faster over the years. I should try a comparison on a simple kernel build someday. > > > > > 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? > > And by the way, thank you for reviewing this patch series! I'll go into a deeper review if we proceed. > > > > 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. Right, but like I said, even servers can sometimes find a moment to think about their good life. > > And given the numbers you provided with your measurements, I bet this will > > be significant with !NOCB as well. This is not only delaying callbacks execution, > > this also reduces the frequency of grace periods, and that impact should be > > quite visible. > > > > Note I'm not stricly opposed to the current approach. But I can't say I'm > > comfortable with it. > > > > Can we do a simple test? Would it be possible to affine every rcuo%c/%d kthread > > to the corresponding CPU%d? For example affine rcuop/1 to CPU 1, rcuop/2 to > > CPU2, etc... And then relaunch your measurements on top of that? > > > > The point is that having the callback kthreads affined to their corresponding > > CPUs should elude the power saving advantages of rcu_nocbs=, back to roughly > > a !NOCB behaviour powerwise (except we have context switches). If you find good > > numbers with this setup then you'll find good numbers with !NOCB. > > 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. Thanks.
On Mon, Aug 29, 2022 at 01:42:02PM -0700, Paul E. McKenney wrote: > On Mon, Aug 29, 2022 at 04:36:40PM -0400, Joel Fernandes wrote: > > On Mon, Aug 29, 2022 at 3:46 PM Frederic Weisbecker <frederic@kernel.org> wrote: > > > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > > > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: > > [ . . . ] > > > > > > 2) NOCB implies performance issues. > > > > > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > > > > with the extra scheduling overhead of the extra threads which is usually not a > > > > problem except that RCU is used in the critical path of boot up (on ChromeOS). > > > > > > I never measured it myself but executing callbacks on another CPUs, with > > > context switches and locking can only involve significant performance issues if callbacks > > > are frequent. So it's a tradeoff between power and performance. > > > > In my testing of benchmarks on real systems with 8-16 CPUs, the > > performance hit is down in the noise. It is possible though that maybe > > one can write a non-realistic synthetic test to force the performance > > issues, but I've not seen it in the real world. Maybe on > > networking-heavy servers with lots of cores, you'll see it but their > > batteries if any would be pretty big :-). > > To Frederic's point, if you have enough servers, even a 1% decrease in > power consumption is a very big deal. ;-) The world has enough servers, for that matters ;-)
On Mon, Aug 29, 2022 at 04:48:25PM -0400, Joel Fernandes wrote: > On Mon, Aug 29, 2022 at 4:42 PM Paul E. McKenney <paulmck@kernel.org> wrote: > > > > On Mon, Aug 29, 2022 at 04:36:40PM -0400, Joel Fernandes wrote: > > > On Mon, Aug 29, 2022 at 3:46 PM Frederic Weisbecker <frederic@kernel.org> wrote: > > > > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > > > > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: > > > > [ . . . ] > > > > > > > > 2) NOCB implies performance issues. > > > > > > > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > > > > > with the extra scheduling overhead of the extra threads which is usually not a > > > > > problem except that RCU is used in the critical path of boot up (on ChromeOS). > > > > > > > > I never measured it myself but executing callbacks on another CPUs, with > > > > context switches and locking can only involve significant performance issues if callbacks > > > > are frequent. So it's a tradeoff between power and performance. > > > > > > In my testing of benchmarks on real systems with 8-16 CPUs, the > > > performance hit is down in the noise. It is possible though that maybe > > > one can write a non-realistic synthetic test to force the performance > > > issues, but I've not seen it in the real world. Maybe on > > > networking-heavy servers with lots of cores, you'll see it but their > > > batteries if any would be pretty big :-). > > > > To Frederic's point, if you have enough servers, even a 1% decrease in > > power consumption is a very big deal. ;-) > > Ah I see Frederick's point now, so basically the claim is that using > lazy-RCU on servers might make sense to save power because > CONFIG_RCU_NO_CB_CPU may not be an option there (networking throughput > and so forth). > > That's a good point indeed... You got it! And it's not just servers but pretty much everything that may be idle sometimes. Distros (except android then) don't use rcu_nocbs= by default. Routers enjoy night bandwith, etc... Thanks!
On Tue, Aug 30, 2022 at 12:53:24PM +0200, Frederic Weisbecker wrote: > On Mon, Aug 29, 2022 at 01:42:02PM -0700, Paul E. McKenney wrote: > > On Mon, Aug 29, 2022 at 04:36:40PM -0400, Joel Fernandes wrote: > > > On Mon, Aug 29, 2022 at 3:46 PM Frederic Weisbecker <frederic@kernel.org> wrote: > > > > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > > > > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: > > > > [ . . . ] > > > > > > > > 2) NOCB implies performance issues. > > > > > > > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > > > > > with the extra scheduling overhead of the extra threads which is usually not a > > > > > problem except that RCU is used in the critical path of boot up (on ChromeOS). > > > > > > > > I never measured it myself but executing callbacks on another CPUs, with > > > > context switches and locking can only involve significant performance issues if callbacks > > > > are frequent. So it's a tradeoff between power and performance. > > > > > > In my testing of benchmarks on real systems with 8-16 CPUs, the > > > performance hit is down in the noise. It is possible though that maybe > > > one can write a non-realistic synthetic test to force the performance > > > issues, but I've not seen it in the real world. Maybe on > > > networking-heavy servers with lots of cores, you'll see it but their > > > batteries if any would be pretty big :-). > > > > To Frederic's point, if you have enough servers, even a 1% decrease in > > power consumption is a very big deal. ;-) > > The world has enough servers, for that matters ;-) True enough! Now you need only demonstrate that call_rcu_lazy() for !rcu_nocbs servers would actually deliver that 1%. ;-) Thanx, Paul
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
On Tue, Aug 30, 2022 at 12:43:44PM +0200, Frederic Weisbecker wrote: > On Mon, Aug 29, 2022 at 12:57:30PM -0700, Paul E. McKenney wrote: > > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > > > While I agree with you that perhaps making it more generic is better, this did > > > take a significant amount of time, testing and corner case hunting to come up > > > with, and v5 is also in the works so I'd appreciate if we can do it the > > > bypass-way and optimize later. Arguably the bypass way is quite simple and > > > allows us to leverage its effects of rcu_barrier and such. And the API will not > > > change. > > > > Just confirming this conversation, on the hopefully unlikely off-chance > > that there is any doubt. ;-) > > > > That said, if there is some compelling use case that is not addressed > > by rcu_nocbs, keeping in mind that these can now be made dynamic, then > > some adjustment will of course be needed. > > Right there is that too. But we do need the use case before changing the current direction. Otherwise, all we are doing is slowing down the arrival of energy efficiency for a very large number of systems for which we know that there is a call_rcu_lazy() benefit. Yes, doing the work twice might seem unattractive, but for purposes of comparison, I did the CONFIG_RCU_FAST_NO_HZ eight or nine times before I got something that saved significant real power on real hardware. And in the end, CONFIG_RCU_FAST_NO_HZ was removed due to lack of use compared to rcu_nocbs. ;-) > > > > Several highlights: > > > > > > > > 1) NOCB is most often needed for nohz_full and the latter has terrible power > > > > management. The CPU 0 is active all the time there. > > > > > > I see. We don't use nohz_full much. NOCB itself gives good power improvement. > > > > > > > 2) NOCB without nohz_full has extremely rare usecase (RT niche: > > > > https://lore.kernel.org/lkml/CAFzL-7vqTX-y06Kc3HaLqRWAYE0d=ms3TzVtZLn0c6ATrKD+Qw@mail.gmail.com/ > > > > ) > > > > > > Really? Android has been using it for a long time. It seems to be quite popular > > > in the battery-powered space. > > > > > > > 2) NOCB implies performance issues. > > > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > > > with the extra scheduling overhead of the extra threads which is usually not a > > > problem except that RCU is used in the critical path of boot up (on ChromeOS). > > > > Back in 2010, Rik van Riel reported significant slowdowns for some types > > of Java workloads, but for normal servers, not Android or ChromeOS. > > I have no idea whether similar slowdowns exist today. But if there is > > no performance advantage to non-offloaded callbacks, we should first make > > offloading the default, and if there are no complaints after a few years, > > remove the non-offloaded case completely. > > My gut feeling is that this is a bad idea. Yet I have no practical proof :o) Indeed, the burden of proof is on those who believe that such slowdowns have somehow vanished over the past 12 years. ;-) > > My guess is that at the very least, scheduler corner cases will force > > us to keep non-offloaded callbacks, but you never know. In any case, > > a wakeup is considerably more expensive than a non-atomic OR of a bit > > in a per-CPU variable, so there is some chance that offloading causes > > some important workloads considerable performance degradation. > > Definetly! > > > > > > > 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. > > > > It has been getting simpler! ;-) > > > > I bet that the lazy_len field can be a boolean and independent of > > ->cblist, and that doing that would simplify things at least a little bit. > > But, yes, an all-lazy indicator of some sort would still need to exist. > > Yeah, I'll check the patch in detail. Much appreciated! I believe that the upcoming v5 has some significant differences from v4. > > > > 4) This is further complexifying bypass core code, nocb timer management, core > > > > nocb group management, all of which being already very complicated. > > > > > > True, I agree, a few more cases to handle for sure, but I think I got them all > > > now (hopefully). > > > > If we do need lazy callbacks on non-offloaded CPUs, there will need to > > be changes to both the bypass logic (possibly just those changes that > > Joel already has, but Murphy might disagree) and to the ->cblist logic. > > At the very least, the wakeup logic would need adjustment from current > > -rcu and there would still need to be some way of tracking whether or > > not all the callbacks in the bypass list are lazy. > > Sure but we can arrange for pushing the complexity in a common place between > NOCB and !NOCB. Easy to say, easy to say... ;-) > > > > 5) The !NOCB implementation is going to be very different > > > > > > > > Ok I can admit one counter argument in favour of using NO_CB: > > > > > > > > -1) The scheduler can benefit from a wake CPU to run the callbacks on behalf of a bunch > > > > of idle CPUs, instead of waking up that bunch of CPUs. But still we are dealing > > > > with callbacks that can actually wait... > > > > You lost me on this one. Having a callback invoked on a non-idle CPU > > should save significant power without significant delay in callback > > invocation. What am I missing here? > > The thing is that if the callback can wait, and does actually, then the > advantage of call_rcu_lazy() should be visible whether the callbacks are > offloaded or not. Except that in common configurations of NOCB, the scheduler has much more freedom to move the work to non-idle CPUs. Plus in Joel et al.'s testing, it was the reduced number of grace periods that provided the power savings. So if a grace period is happening anyway, then I know of no benefit from deferring lazy callbacks. (Which is why I was suggesting marking laziness of RCU_NEXT_READY_TAIL as well as RCU_NEXT_TAIL.) > > > Yeah that's huge. Significant amount of power improvement seems to come from > > > idle CPUs not being disturbed and their corresponding timer ticks turned off for > > > longer periods. That's experimentally confirmed (NO_CB giving significant power > > > improvement on battery-power systems as compared to !NO_CB). > > > > > > > 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 is certainly good to look into alternatives! Especially if this has > > somehow broken (de)offloading. (Not seeing it in my testing, but then > > again, I have not yet tested this series all that much.) > > > > How does the separate RCU_LAZY_TAIL segment help? I would think > > that you would instead want an all-lazy flag on each of the existing > > RCU_NEXT_READY_TAIL and RCU_NEXT_TAIL segments. After all, if there is > > even one non-lazy callback in either segment, we need the corresponding > > grace period to run sooner rather than later. And if we are running a > > given grace period anyway, it costs little to handle the lazy callbacks > > while we are at it. > > Good point! That sounds much better. > > > Or is there a use case where it helps a lot to defer lazy callbacks that > > could have been handled by a grace period that needed to happen anyway, > > due to the presence of non-lazy callbacks? I am having a hard time coming > > up with one, but perhaps that is a failure of imagination on my part. > > I don't see one right now. Perhaps there isn't one, or perhaps Murphy is waiting to teach us both a lesson. ;-) > > There would still need to be changes to the bypass code because NOCB is > > what gets both Android and ChromeOS big power savings. > > Actually using the flag on RCU_NEXT_TAIL and RCU_NEXT_READ_TAIL would > avoid touching the bypass code. > > I see a big advantage in that we don't mix up two orthogonal things anymore: > flooding callbacks (normal bypass) and callbacks that can actually wait > (lazy callbacks), both needing a different treatment. At the very least, the bypass code would need to change in order to track the laziness of the bypassing callbacks. Plus wouldn't there need to be some adjustment of was_alldone indication to the caller of rcu_nocb_try_bypass() in order to avoid that caller starting a grace period that should have been lazily deferred? Or am I missing a trick here? And again, touching ->cblist increase risk to workloads that are not yet known to benefit from call_rcu_lazy(). > > And yes, no matter what, rcu_barrier_entrain() needs to motivate any lazy > > callbacks. Currently, this falls out from the flushing of the bypass. > > Presumably, offloading and deoffloading could also take advantage of > > bypass flushing. > > > > And I have no idea whether it would make sense for the NOCB and !NOCB > > case to share a laziness-motivation timer. > > No at least the timer will need to be different. It should integrate into > the existing one in NOCB whereas !NOCB should have something more simple. I would guess that we will find a devil or two in those details. > > > 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? > > > > And if they are not using NOCB, does call_rcu_lazy() actually help? > > I suspect yes, due to the frequency of grace periods lowering. But your suspicion rests on the assumption that server workloads often have nothing but lazy callbacks queued, correct? If so, what is a good way to check that assumption? Measure the fraction of full seconds during which nothing but lazy callbacks are queued? Measure the fraction of grace periods that handled only lazy callbacks? Or is there some better approach? Thanx, Paul
On Tue, Aug 30, 2022 at 04:43:43AM -0700, Paul E. McKenney wrote: > On Tue, Aug 30, 2022 at 12:53:24PM +0200, Frederic Weisbecker wrote: > > On Mon, Aug 29, 2022 at 01:42:02PM -0700, Paul E. McKenney wrote: > > > On Mon, Aug 29, 2022 at 04:36:40PM -0400, Joel Fernandes wrote: > > > > On Mon, Aug 29, 2022 at 3:46 PM Frederic Weisbecker <frederic@kernel.org> wrote: > > > > > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > > > > > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: > > > > > > [ . . . ] > > > > > > > > > > 2) NOCB implies performance issues. > > > > > > > > > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > > > > > > with the extra scheduling overhead of the extra threads which is usually not a > > > > > > problem except that RCU is used in the critical path of boot up (on ChromeOS). > > > > > > > > > > I never measured it myself but executing callbacks on another CPUs, with > > > > > context switches and locking can only involve significant performance issues if callbacks > > > > > are frequent. So it's a tradeoff between power and performance. > > > > > > > > In my testing of benchmarks on real systems with 8-16 CPUs, the > > > > performance hit is down in the noise. It is possible though that maybe > > > > one can write a non-realistic synthetic test to force the performance > > > > issues, but I've not seen it in the real world. Maybe on > > > > networking-heavy servers with lots of cores, you'll see it but their > > > > batteries if any would be pretty big :-). > > > > > > To Frederic's point, if you have enough servers, even a 1% decrease in > > > power consumption is a very big deal. ;-) > > > > The world has enough servers, for that matters ;-) > > True enough! Now you need only demonstrate that call_rcu_lazy() for > !rcu_nocbs servers would actually deliver that 1%. ;-) Well, !rcu_nocbs is not only used by server but also by pretty much everything else, except android IIUC. I can't really measure the whole world but I don't see how the idleness of a server/router/desktop/embedded/rt/hpc device differs from the idleness of an android device. But ok I'll try to measure that.
On Tue, Aug 30, 2022 at 06:03:16PM +0200, Frederic Weisbecker wrote: > On Tue, Aug 30, 2022 at 04:43:43AM -0700, Paul E. McKenney wrote: > > On Tue, Aug 30, 2022 at 12:53:24PM +0200, Frederic Weisbecker wrote: > > > On Mon, Aug 29, 2022 at 01:42:02PM -0700, Paul E. McKenney wrote: > > > > On Mon, Aug 29, 2022 at 04:36:40PM -0400, Joel Fernandes wrote: > > > > > On Mon, Aug 29, 2022 at 3:46 PM Frederic Weisbecker <frederic@kernel.org> wrote: > > > > > > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > > > > > > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: > > > > > > > > [ . . . ] > > > > > > > > > > > > 2) NOCB implies performance issues. > > > > > > > > > > > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > > > > > > > with the extra scheduling overhead of the extra threads which is usually not a > > > > > > > problem except that RCU is used in the critical path of boot up (on ChromeOS). > > > > > > > > > > > > I never measured it myself but executing callbacks on another CPUs, with > > > > > > context switches and locking can only involve significant performance issues if callbacks > > > > > > are frequent. So it's a tradeoff between power and performance. > > > > > > > > > > In my testing of benchmarks on real systems with 8-16 CPUs, the > > > > > performance hit is down in the noise. It is possible though that maybe > > > > > one can write a non-realistic synthetic test to force the performance > > > > > issues, but I've not seen it in the real world. Maybe on > > > > > networking-heavy servers with lots of cores, you'll see it but their > > > > > batteries if any would be pretty big :-). > > > > > > > > To Frederic's point, if you have enough servers, even a 1% decrease in > > > > power consumption is a very big deal. ;-) > > > > > > The world has enough servers, for that matters ;-) > > > > True enough! Now you need only demonstrate that call_rcu_lazy() for > > !rcu_nocbs servers would actually deliver that 1%. ;-) > > Well, !rcu_nocbs is not only used by server but also by pretty much > everything else, except android IIUC. I can't really measure the whole > world but I don't see how the idleness of a server/router/desktop/embedded/rt/hpc > device differs from the idleness of an android device. > > But ok I'll try to measure that. 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.
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. In "light" loaded test cases, especially where a power drain is a key thing, such light load may lead to some kind of "noise" produced by the RCU core, i.e. kicking idle CPUs, thus wasting power. On our ARM devices it is not painful, but there is a small power gain and it is visible. For other systems, like Joel measures for Intel SoC it is more visible, because of a power cost getting in/out of isle states. This is what i see on my setup. -- Uladzislau Rezki
On Tue, Aug 30, 2022 at 06:22:44PM +0200, Frederic Weisbecker wrote: > On Tue, Aug 30, 2022 at 06:03:16PM +0200, Frederic Weisbecker wrote: > > On Tue, Aug 30, 2022 at 04:43:43AM -0700, Paul E. McKenney wrote: > > > On Tue, Aug 30, 2022 at 12:53:24PM +0200, Frederic Weisbecker wrote: > > > > On Mon, Aug 29, 2022 at 01:42:02PM -0700, Paul E. McKenney wrote: > > > > > On Mon, Aug 29, 2022 at 04:36:40PM -0400, Joel Fernandes wrote: > > > > > > On Mon, Aug 29, 2022 at 3:46 PM Frederic Weisbecker <frederic@kernel.org> wrote: > > > > > > > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: > > > > > > > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: > > > > > > > > > > [ . . . ] > > > > > > > > > > > > > > 2) NOCB implies performance issues. > > > > > > > > > > > > > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do > > > > > > > > with the extra scheduling overhead of the extra threads which is usually not a > > > > > > > > problem except that RCU is used in the critical path of boot up (on ChromeOS). > > > > > > > > > > > > > > I never measured it myself but executing callbacks on another CPUs, with > > > > > > > context switches and locking can only involve significant performance issues if callbacks > > > > > > > are frequent. So it's a tradeoff between power and performance. > > > > > > > > > > > > In my testing of benchmarks on real systems with 8-16 CPUs, the > > > > > > performance hit is down in the noise. It is possible though that maybe > > > > > > one can write a non-realistic synthetic test to force the performance > > > > > > issues, but I've not seen it in the real world. Maybe on > > > > > > networking-heavy servers with lots of cores, you'll see it but their > > > > > > batteries if any would be pretty big :-). > > > > > > > > > > To Frederic's point, if you have enough servers, even a 1% decrease in > > > > > power consumption is a very big deal. ;-) > > > > > > > > The world has enough servers, for that matters ;-) > > > > > > True enough! Now you need only demonstrate that call_rcu_lazy() for > > > !rcu_nocbs servers would actually deliver that 1%. ;-) > > > > Well, !rcu_nocbs is not only used by server but also by pretty much > > everything else, except android IIUC. And soon, ChromeOS. > > I can't really measure the whole > > world but I don't see how the idleness of a server/router/desktop/embedded/rt/hpc > > device differs from the idleness of an android device. > > > > But ok I'll try to measure that. > > 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. Sounds like a good start. And yes, we don't need to show that the whole !NOCB world needs this, just some significant portion of it. But we do need some decent evidence. After all, it is all too easy to do a whole lot of work and find that the expected benefits fail to materialize. Thanx, Paul
Hi Frederick, On 8/30/2022 6:26 AM, Frederic Weisbecker wrote: > On Mon, Aug 29, 2022 at 04:36:40PM -0400, Joel Fernandes wrote: [..] >>>>> 2) NOCB without nohz_full has extremely rare usecase (RT niche: >>>>> https://lore.kernel.org/lkml/CAFzL-7vqTX-y06Kc3HaLqRWAYE0d=ms3TzVtZLn0c6ATrKD+Qw@mail.gmail.com/ >>>>> ) >>>> >>>> Really? Android has been using it for a long time. It seems to be quite popular >>>> in the battery-powered space. >>> >>> It's really sad that this is the first time I hear about that. I've been working >>> on this code for years now without this usecase in mind. And yet it's fundamental. >>> >>> I asked several times around about other usecases of rcu_nocbs than nohz_full= >>> and nobody reported that. I can hardly even google a significant link >>> between power saving and rcu_nocbs= >>> >>> If this is really used that way for a long time then it's a cruel disconnection >>> between users and developers. >> >> I was not involved with Android or RCU back then. But my guess is I >> don't think it was enabled with the intent of saving power, it is just >> that using RCU_NO_CB_CPU has become the way to go to keep dynick-idle >> CPUs undisturbed: https://paulmck.livejournal.com/66807.html . Paul , >> +Dietmar Eggemann can probably provide more history. > > Thanks for the pointer! No problem. Paul proves to us that any and every bit of writing effort pays off in one way or the other :-D. >>>>> 2) NOCB implies performance issues. >>>> >>>> Which kinds of? There is slightly worse boot times, but I'm guessing that's do >>>> with the extra scheduling overhead of the extra threads which is usually not a >>>> problem except that RCU is used in the critical path of boot up (on ChromeOS). >>> >>> I never measured it myself but executing callbacks on another CPUs, with >>> context switches and locking can only involve significant performance issues if callbacks >>> are frequent. So it's a tradeoff between power and performance. >> >> In my testing of benchmarks on real systems with 8-16 CPUs, the >> performance hit is down in the noise. It is possible though that maybe >> one can write a non-realistic synthetic test to force the performance >> issues, but I've not seen it in the real world. Maybe on >> networking-heavy servers with lots of cores, you'll see it but their >> batteries if any would be pretty big :-). > > Yeah I suspect this should have an impact on servers. And even servers may > deserve idleness sometimes. Sure. I think I am pretty sure you will see power savings on servers but I guess the big question is will you regress server workloads with those savings. I do remember, Eric Dumazet from Google posting to LKML that callback flooding can happen on servers. >>>>> 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. >> >> To Paul's point, we can change it to a flag I think. The 3 states are: >> - no CBs. >> - All lazy >> - All non-lazy > > Yeah that makes sense, should we take the generic direction! Sure, thanks. >> >> Or, worse case, we can move the flag to the per-cpu rcu_data >> structure, I think. Does that alleviate your concern? >> >>>>> 4) This is further complexifying bypass core code, nocb timer management, core >>>>> nocb group management, all of which being already very complicated. >>>> >>>> True, I agree, a few more cases to handle for sure, but I think I got them all >>>> now (hopefully). >>> >>> Now I'm worried about maintainability. Hence why I'd rather see a generic code >>> for them all if possible. >> >> Maintainability is a concern for any new code. I rely a lot on testing >> both synthetic, and real-world. I have spent a lot of time on test >> code on this. > > And I thank you for that. I've always been terrible at performance/power/latency > testing so I'm always relieved when others take over on that :) Thanks, appreciate it. >>> >>> Note I'm not stricly opposed to the current approach. But I can't say I'm >>> comfortable with it. >> >> Maybe we can find a way in the code to see what can be changed. One >> concern you rightly raised is the length variables , but I think >> that's not a blocker. > > That's just a detail indeed. If we proceed with the current NOCB approach I'll > give a deeper review. > >> >>> Can we do a simple test? Would it be possible to affine every rcuo%c/%d kthread >>> to the corresponding CPU%d? For example affine rcuop/1 to CPU 1, rcuop/2 to >>> CPU2, etc... And then relaunch your measurements on top of that? >> >> We already did that and it does not help, it makes things worse. The >> decision of where to run RCU threads is best left to the scheduler >> (for both performance and power). > > That's the point, we want to artificially remove NOCB advantages to get > a behaviour close to !NOCB, so that we know if it's worth expanding the > patchset to !NOCB. > Let me clarify. The point of NOCB, powerwise, is that the RCU kthreads > track and execute the callbacks to an optimized selection of CPUs, thanks to the > scheduler. And the new lazy flow optimize that further. > > Now we would like to know if call_rcu_lazy() also works on !NOCB. But we have > no way to test that right now because we only have an implemention for NOCB. I am happy to try this, but I want to make a counter-suggestion. You can 'hack' a behavior similar to call_rcu_lazy() by just increasing jiffiest_till_first_fqs to 24 or 48 (via boot param). The downside of doing this, you'll slow down synchronize_rcu() and tracing will be slow. That can be remedied by passing rcupdate.rcu_expedited boot parameter to speed up synchronous_rcu(). However, it will still slow down *all* call_rcu(). Neverthless, its a neat trick to see the light at the end of the tunnel but not for product. Would it be possible for you try this out with some workloads on a server, or even the server just being idle? Just to mention - the power savings between NO_CB and !NO_CB is enormous for us (40% !!). We attributed this directly to the tick not getting turned off and the hardware SoC thus not entering a deeper SoC-wide lower state (known as package C-state). While a server does not typically have an SoC, I suspect *some* power savings at least. > But if we affine each rcuop/%d to their corresponding CPU%d, we get a behaviour > that is close to !NOCB because then the scheduler doesn't help anymore and > callbacks are executed locally (the only difference is that we do context > switches, locking and and we still have rcuog around but still, that > should give a rough idea of what we get with !NOCB). > > Therefore if you test your measurements again before and after your patchset, > both with each rcuop/%d affine to their CPU%d counterpart, you should get a > comparison of before VS after your patchset on what would be an implementation > on !NOCB. My suspicion is that if I did this experiment on my hardware, it will still not give you a good idea of what a server will see. Because I don't have those kind of workloads or many-CPU hardware. So it may not be that representative of what the !NOCB world wants. Further, my hardware is an Intel SoC which is more integrated than a typical server board so SoC-wide power savings might not be representative of the server hardware. However, I am happy to try out your suggestion out of respect for you, if you still feel its worth doing. Thanks, - Joel
On 8/30/2022 12:22 PM, Frederic Weisbecker wrote: > On Tue, Aug 30, 2022 at 06:03:16PM +0200, Frederic Weisbecker wrote: >> On Tue, Aug 30, 2022 at 04:43:43AM -0700, Paul E. McKenney wrote: >>> On Tue, Aug 30, 2022 at 12:53:24PM +0200, Frederic Weisbecker wrote: >>>> On Mon, Aug 29, 2022 at 01:42:02PM -0700, Paul E. McKenney wrote: >>>>> On Mon, Aug 29, 2022 at 04:36:40PM -0400, Joel Fernandes wrote: >>>>>> On Mon, Aug 29, 2022 at 3:46 PM Frederic Weisbecker <frederic@kernel.org> wrote: >>>>>>> On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: >>>>>>>> On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: >>>>> >>>>> [ . . . ] >>>>> >>>>>>>>> 2) NOCB implies performance issues. >>>>>>>> >>>>>>>> Which kinds of? There is slightly worse boot times, but I'm guessing that's do >>>>>>>> with the extra scheduling overhead of the extra threads which is usually not a >>>>>>>> problem except that RCU is used in the critical path of boot up (on ChromeOS). >>>>>>> >>>>>>> I never measured it myself but executing callbacks on another CPUs, with >>>>>>> context switches and locking can only involve significant performance issues if callbacks >>>>>>> are frequent. So it's a tradeoff between power and performance. >>>>>> >>>>>> In my testing of benchmarks on real systems with 8-16 CPUs, the >>>>>> performance hit is down in the noise. It is possible though that maybe >>>>>> one can write a non-realistic synthetic test to force the performance >>>>>> issues, but I've not seen it in the real world. Maybe on >>>>>> networking-heavy servers with lots of cores, you'll see it but their >>>>>> batteries if any would be pretty big :-). >>>>> >>>>> To Frederic's point, if you have enough servers, even a 1% decrease in >>>>> power consumption is a very big deal. ;-) >>>> >>>> The world has enough servers, for that matters ;-) >>> >>> True enough! Now you need only demonstrate that call_rcu_lazy() for >>> !rcu_nocbs servers would actually deliver that 1%. ;-) >> >> Well, !rcu_nocbs is not only used by server but also by pretty much >> everything else, except android IIUC. I can't really measure the whole >> world but I don't see how the idleness of a server/router/desktop/embedded/rt/hpc >> device differs from the idleness of an android device. >> >> But ok I'll try to measure that. > > 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. One potential usecase could be logging if the logger is opening and closing log files during logging updates. Uladzislau reported this on Android, that a system logger was doing file open/close and triggering RCU that way (file table, dentry, inode code all queue RCU callbacks). Thanks, - Joel
On 8/30/2022 12:44 PM, 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. > > In "light" loaded test cases, especially where a power drain is a key > thing, such light load may lead to some kind of "noise" produced by the > RCU core, i.e. kicking idle CPUs, thus wasting power. On our ARM devices > it is not painful, but there is a small power gain and it is visible. > For other systems, like Joel measures for Intel SoC it is more visible, > because of a power cost getting in/out of isle states. Indeed! And Intel (Rushikesh) reminded me today that it has become more important than before to not disturb idle CPUs, because more and more pieces of hardware are moving into SoCs. So if the whole SoC cannot go into deeper sleep state (package C-state) because of the CPU getting disturbed, then that's lesser power savings than say in the not-so-recent past. Rushikesh could shed more light on that fact. Thanks, - Joel
On Tue, Aug 30, 2022 at 09:46:34AM -0700, Paul E. McKenney wrote: > > 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. > > Sounds like a good start. > > And yes, we don't need to show that the whole !NOCB world needs this, > just some significant portion of it. But we do need some decent evidence. > After all, it is all too easy to do a whole lot of work and find that > the expected benefits fail to materialize. So here is some quick test. I made a patch that replaces Joel's 1st patch with an implementation of call_rcu_lazy() that queues lazy callbacks through the regular call_rcu() way but it counts them in a lazy_count. Upon idle entry it reports whether the tick is retained solely by lazy callbacks or not. I get periodic and frequent results on my idle test box, something must be opening/closing some file periodically perhaps. Anyway the thing can be tested with this branch: git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git rcu/lazy-trace Excerpt: <idle>-0 [007] d..1. 414.226966: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 414.228271: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 414.232269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 414.236269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 414.468048: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 414.468268: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 414.472268: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 414.476269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 419.500577: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 419.504253: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 419.508250: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 419.512249: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 419.566881: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 419.568252: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 419.572249: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 419.576255: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 424.666873: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 424.668233: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 424.672230: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 424.676232: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 424.737283: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 424.740233: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 424.744230: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 424.748231: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 429.767922: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 429.768209: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 429.772212: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 429.776212: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 429.972931: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 429.976214: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 429.980211: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 429.984212: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [003] d..1. 430.402139: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [003] d..1. 430.404211: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [003] d..1. 430.404290: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [003] d..1. 430.408235: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [003] d..1. 430.408304: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [003] d..1. 430.412215: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle Thanks.
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. Also in !NOCB, pending callbacks retain the timer tick of a CPU (see rcu_needs_cpu()), and cpuidle relies on the tick to be stopped before allowing the CPU into low power mode. So a lazy callback may delay a CPU from entering into low power mode for a few milliseconds. And I can observe those retained ticks on my idle box. Thanks.
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. > > Also in !NOCB, pending callbacks retain the timer tick of a CPU (see > rcu_needs_cpu()), and cpuidle relies on the tick to be stopped before > allowing the CPU into low power mode. So a lazy callback may delay a CPU from > entering into low power mode for a few milliseconds. > > And I can observe those retained ticks on my idle box. > Maybe !NOCB is more about performance. But i have no clue about workloads and if such workloads exist nowadays. -- Uladzislau Rezki
On Wed, Aug 31, 2022 at 05:26:58PM +0200, Frederic Weisbecker wrote: > On Tue, Aug 30, 2022 at 09:46:34AM -0700, Paul E. McKenney wrote: > > > 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. > > > > Sounds like a good start. > > > > And yes, we don't need to show that the whole !NOCB world needs this, > > just some significant portion of it. But we do need some decent evidence. > > After all, it is all too easy to do a whole lot of work and find that > > the expected benefits fail to materialize. > > So here is some quick test. I made a patch that replaces Joel's 1st patch > with an implementation of call_rcu_lazy() that queues lazy callbacks > through the regular call_rcu() way but it counts them in a lazy_count. > > Upon idle entry it reports whether the tick is retained solely by lazy > callbacks or not. > > I get periodic and frequent results on my idle test box, something must be > opening/closing some file periodically perhaps. > > Anyway the thing can be tested with this branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > rcu/lazy-trace > > Excerpt: > > <idle>-0 [007] d..1. 414.226966: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 414.228271: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 414.232269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 414.236269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle Just to make sure that I understand, at this point, there is only the one lazy callback (and no non-lazy callbacks) on this CPU, and that CPU is therefore keeping the tick on only for the benefit of that one lazy callback. And for the above four traces, this is likely the same lazy callback. Did I get it right, or is there something else going on? Thanx, Paul > <idle>-0 [007] d..1. 414.468048: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 414.468268: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 414.472268: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 414.476269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 419.500577: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 419.504253: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 419.508250: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 419.512249: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 419.566881: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 419.568252: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 419.572249: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 419.576255: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 424.666873: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 424.668233: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 424.672230: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 424.676232: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 424.737283: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 424.740233: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 424.744230: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 424.748231: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 429.767922: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 429.768209: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 429.772212: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 429.776212: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 429.972931: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 429.976214: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 429.980211: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 429.984212: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [003] d..1. 430.402139: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [003] d..1. 430.404211: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [003] d..1. 430.404290: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [003] d..1. 430.408235: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [003] d..1. 430.408304: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [003] d..1. 430.412215: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > > Thanks.
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. Thanx, Paul > > Also in !NOCB, pending callbacks retain the timer tick of a CPU (see > > rcu_needs_cpu()), and cpuidle relies on the tick to be stopped before > > allowing the CPU into low power mode. So a lazy callback may delay a CPU from > > entering into low power mode for a few milliseconds. > > > > And I can observe those retained ticks on my idle box. > > > Maybe !NOCB is more about performance. But i have no clue about > workloads and if such workloads exist nowadays. > > -- > Uladzislau Rezki
On Thu, Sep 01, 2022 at 07:39:07AM -0700, Paul E. McKenney wrote: > On Wed, Aug 31, 2022 at 05:26:58PM +0200, Frederic Weisbecker wrote: > > On Tue, Aug 30, 2022 at 09:46:34AM -0700, Paul E. McKenney wrote: > > > > 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. > > > > > > Sounds like a good start. > > > > > > And yes, we don't need to show that the whole !NOCB world needs this, > > > just some significant portion of it. But we do need some decent evidence. > > > After all, it is all too easy to do a whole lot of work and find that > > > the expected benefits fail to materialize. > > > > So here is some quick test. I made a patch that replaces Joel's 1st patch > > with an implementation of call_rcu_lazy() that queues lazy callbacks > > through the regular call_rcu() way but it counts them in a lazy_count. > > > > Upon idle entry it reports whether the tick is retained solely by lazy > > callbacks or not. > > > > I get periodic and frequent results on my idle test box, something must be > > opening/closing some file periodically perhaps. > > > > Anyway the thing can be tested with this branch: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > > rcu/lazy-trace > > > > Excerpt: > > > > <idle>-0 [007] d..1. 414.226966: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > > <idle>-0 [007] d..1. 414.228271: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > > <idle>-0 [007] d..1. 414.232269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > > <idle>-0 [007] d..1. 414.236269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > > Just to make sure that I understand, at this point, there is only the > one lazy callback (and no non-lazy callbacks) on this CPU, and that > CPU is therefore keeping the tick on only for the benefit of that one > lazy callback. And for the above four traces, this is likely the same > lazy callback. > > Did I get it right, or is there something else going on? Exactly that! Thanks.
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. I'm sorry but I still feel confused reading that !NOCB is not about power save. To me everything is about power save. NOCB just appears to help optimizing it without significant tradeoff on some given workloads. > In this scenario you can not let the EAS scheduler to find a more > efficient CPU for further handling. Sure but that doesn't mean there wouldn't be a power saving gain anyway. Thanks.
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. 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. Thanks.
On 9/1/2022 11:13 AM, Frederic Weisbecker 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. > > I'm sorry but I still feel confused reading that !NOCB is not about power > save. To me everything is about power save. NOCB just appears to help optimizing > it without significant tradeoff on some given workloads. Right, I think Fred is coming from the reasonable perspective of "Save power by making !NOCB RCU do less" (i.e. delay softirq, main GP thread, QS reports etc) which I think is also valid (not sure how much power that saves on servers but sounds reasonable to measure). When you hack your implementation to test that, it would be reasonable to also apply the old FAST NOHZ patch and measure with/without that. > >> In this scenario you can not let the EAS scheduler to find a more >> efficient CPU for further handling. > > Sure but that doesn't mean there wouldn't be a power saving gain anyway. Yes there might be. Thanks, - Joel
On 9/1/2022 10:58 AM, Frederic Weisbecker wrote: > On Thu, Sep 01, 2022 at 07:39:07AM -0700, Paul E. McKenney wrote: >> On Wed, Aug 31, 2022 at 05:26:58PM +0200, Frederic Weisbecker wrote: >>> On Tue, Aug 30, 2022 at 09:46:34AM -0700, Paul E. McKenney wrote: >>>>> 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. >>>> >>>> Sounds like a good start. >>>> >>>> And yes, we don't need to show that the whole !NOCB world needs this, >>>> just some significant portion of it. But we do need some decent evidence. >>>> After all, it is all too easy to do a whole lot of work and find that >>>> the expected benefits fail to materialize. >>> >>> So here is some quick test. I made a patch that replaces Joel's 1st patch >>> with an implementation of call_rcu_lazy() that queues lazy callbacks >>> through the regular call_rcu() way but it counts them in a lazy_count. >>> >>> Upon idle entry it reports whether the tick is retained solely by lazy >>> callbacks or not. >>> >>> I get periodic and frequent results on my idle test box, something must be >>> opening/closing some file periodically perhaps. >>> >>> Anyway the thing can be tested with this branch: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git >>> rcu/lazy-trace >>> >>> Excerpt: >>> >>> <idle>-0 [007] d..1. 414.226966: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle >>> <idle>-0 [007] d..1. 414.228271: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle >>> <idle>-0 [007] d..1. 414.232269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle >>> <idle>-0 [007] d..1. 414.236269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle >> >> Just to make sure that I understand, at this point, there is only the >> one lazy callback (and no non-lazy callbacks) on this CPU, and that >> CPU is therefore keeping the tick on only for the benefit of that one >> lazy callback. And for the above four traces, this is likely the same >> lazy callback. >> >> Did I get it right, or is there something else going on? > > Exactly that! Interesting! - Joel
On 9/1/2022 11:30 AM, Frederic Weisbecker wrote: > 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. Sounds good, arguable the core implementation to use bypass list is not too complex or anything, and maybe you can generalize the bypass list for !NONCB as well and re-use most of the code. You will need a per-cpu list anyway (bypass or some other) to queue the CBs. In v1, we had a separate per-cpu list. Thanks for offering to review the patches, you guys really motivate me to work on it (I am currently on leave but still working on it). I'll be looking forward to getting that out soon. Yesterday was good progress. - Joel
On Thu, Sep 01, 2022 at 12:07:56PM -0400, Joel Fernandes wrote: > > > On 9/1/2022 10:58 AM, Frederic Weisbecker wrote: > > On Thu, Sep 01, 2022 at 07:39:07AM -0700, Paul E. McKenney wrote: > >> On Wed, Aug 31, 2022 at 05:26:58PM +0200, Frederic Weisbecker wrote: > >>> On Tue, Aug 30, 2022 at 09:46:34AM -0700, Paul E. McKenney wrote: > >>>>> 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. > >>>> > >>>> Sounds like a good start. > >>>> > >>>> And yes, we don't need to show that the whole !NOCB world needs this, > >>>> just some significant portion of it. But we do need some decent evidence. > >>>> After all, it is all too easy to do a whole lot of work and find that > >>>> the expected benefits fail to materialize. > >>> > >>> So here is some quick test. I made a patch that replaces Joel's 1st patch > >>> with an implementation of call_rcu_lazy() that queues lazy callbacks > >>> through the regular call_rcu() way but it counts them in a lazy_count. > >>> > >>> Upon idle entry it reports whether the tick is retained solely by lazy > >>> callbacks or not. > >>> > >>> I get periodic and frequent results on my idle test box, something must be > >>> opening/closing some file periodically perhaps. > >>> > >>> Anyway the thing can be tested with this branch: > >>> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > >>> rcu/lazy-trace > >>> > >>> Excerpt: > >>> > >>> <idle>-0 [007] d..1. 414.226966: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > >>> <idle>-0 [007] d..1. 414.228271: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > >>> <idle>-0 [007] d..1. 414.232269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > >>> <idle>-0 [007] d..1. 414.236269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > >> > >> Just to make sure that I understand, at this point, there is only the > >> one lazy callback (and no non-lazy callbacks) on this CPU, and that > >> CPU is therefore keeping the tick on only for the benefit of that one > >> lazy callback. And for the above four traces, this is likely the same > >> lazy callback. > >> > >> Did I get it right, or is there something else going on? > > > > Exactly that! Are these callbacks confined to the RCU_NEXT_READY_TAIL and RCU_NEXT_TAIL segments, which are the ones that could (in theory) buffer callbacks without having started a grace period? Or is it all the callbacks regardless of segment? Thanx, Paul
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
On Thu, Sep 01, 2022 at 09:49:28AM -0700, Paul E. McKenney wrote: > > On 9/1/2022 10:58 AM, Frederic Weisbecker wrote: > > > On Thu, Sep 01, 2022 at 07:39:07AM -0700, Paul E. McKenney wrote: > > >> On Wed, Aug 31, 2022 at 05:26:58PM +0200, Frederic Weisbecker wrote: > > >>> On Tue, Aug 30, 2022 at 09:46:34AM -0700, Paul E. McKenney wrote: > > >>>>> 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. > > >>>> > > >>>> Sounds like a good start. > > >>>> > > >>>> And yes, we don't need to show that the whole !NOCB world needs this, > > >>>> just some significant portion of it. But we do need some decent evidence. > > >>>> After all, it is all too easy to do a whole lot of work and find that > > >>>> the expected benefits fail to materialize. > > >>> > > >>> So here is some quick test. I made a patch that replaces Joel's 1st patch > > >>> with an implementation of call_rcu_lazy() that queues lazy callbacks > > >>> through the regular call_rcu() way but it counts them in a lazy_count. > > >>> > > >>> Upon idle entry it reports whether the tick is retained solely by lazy > > >>> callbacks or not. > > >>> > > >>> I get periodic and frequent results on my idle test box, something must be > > >>> opening/closing some file periodically perhaps. > > >>> > > >>> Anyway the thing can be tested with this branch: > > >>> > > >>> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > > >>> rcu/lazy-trace > > >>> > > >>> Excerpt: > > >>> > > >>> <idle>-0 [007] d..1. 414.226966: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > > >>> <idle>-0 [007] d..1. 414.228271: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > > >>> <idle>-0 [007] d..1. 414.232269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > > >>> <idle>-0 [007] d..1. 414.236269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > > >> > > >> Just to make sure that I understand, at this point, there is only the > > >> one lazy callback (and no non-lazy callbacks) on this CPU, and that > > >> CPU is therefore keeping the tick on only for the benefit of that one > > >> lazy callback. And for the above four traces, this is likely the same > > >> lazy callback. > > >> > > >> Did I get it right, or is there something else going on? > > > > > > Exactly that! > > Are these callbacks confined to the RCU_NEXT_READY_TAIL and RCU_NEXT_TAIL > segments, which are the ones that could (in theory) buffer callbacks > without having started a grace period? Or is it all the callbacks > regardless of segment? Ah good point! So I just excluded when those segments have callbacks and I now only get two tick retains every two seconds: <idle>-0 [007] d..1. 1111.893649: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1111.967575: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1113.895470: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1115.669446: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1115.898144: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1117.202833: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1117.900521: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1119.903327: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1120.766864: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1121.909182: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1122.441927: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1123.908911: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1125.868505: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1125.910898: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1127.682837: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1127.913719: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1129.916740: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1130.967052: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1131.919256: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1132.957163: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [000] d..1. 1133.630082: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1133.923053: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1135.927054: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1136.067679: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1137.652294: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1137.932546: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1138.200768: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1139.932573: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1141.167489: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1141.935232: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1143.440538: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle <idle>-0 [007] d..1. 1143.938560: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
On Thu, Sep 01, 2022 at 08:28:04PM +0200, Frederic Weisbecker wrote: > On Thu, Sep 01, 2022 at 09:49:28AM -0700, Paul E. McKenney wrote: > > > On 9/1/2022 10:58 AM, Frederic Weisbecker wrote: > > > > On Thu, Sep 01, 2022 at 07:39:07AM -0700, Paul E. McKenney wrote: > > > >> On Wed, Aug 31, 2022 at 05:26:58PM +0200, Frederic Weisbecker wrote: > > > >>> On Tue, Aug 30, 2022 at 09:46:34AM -0700, Paul E. McKenney wrote: > > > >>>>> 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. > > > >>>> > > > >>>> Sounds like a good start. > > > >>>> > > > >>>> And yes, we don't need to show that the whole !NOCB world needs this, > > > >>>> just some significant portion of it. But we do need some decent evidence. > > > >>>> After all, it is all too easy to do a whole lot of work and find that > > > >>>> the expected benefits fail to materialize. > > > >>> > > > >>> So here is some quick test. I made a patch that replaces Joel's 1st patch > > > >>> with an implementation of call_rcu_lazy() that queues lazy callbacks > > > >>> through the regular call_rcu() way but it counts them in a lazy_count. > > > >>> > > > >>> Upon idle entry it reports whether the tick is retained solely by lazy > > > >>> callbacks or not. > > > >>> > > > >>> I get periodic and frequent results on my idle test box, something must be > > > >>> opening/closing some file periodically perhaps. > > > >>> > > > >>> Anyway the thing can be tested with this branch: > > > >>> > > > >>> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > > > >>> rcu/lazy-trace > > > >>> > > > >>> Excerpt: > > > >>> > > > >>> <idle>-0 [007] d..1. 414.226966: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > > > >>> <idle>-0 [007] d..1. 414.228271: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > > > >>> <idle>-0 [007] d..1. 414.232269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > > > >>> <idle>-0 [007] d..1. 414.236269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > > > >> > > > >> Just to make sure that I understand, at this point, there is only the > > > >> one lazy callback (and no non-lazy callbacks) on this CPU, and that > > > >> CPU is therefore keeping the tick on only for the benefit of that one > > > >> lazy callback. And for the above four traces, this is likely the same > > > >> lazy callback. > > > >> > > > >> Did I get it right, or is there something else going on? > > > > > > > > Exactly that! > > > > Are these callbacks confined to the RCU_NEXT_READY_TAIL and RCU_NEXT_TAIL > > segments, which are the ones that could (in theory) buffer callbacks > > without having started a grace period? Or is it all the callbacks > > regardless of segment? > > Ah good point! > > So I just excluded when those segments have callbacks and I now only get > two tick retains every two seconds: > > <idle>-0 [007] d..1. 1111.893649: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1111.967575: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle But reducing ticks is not the only way energy is saved. The other way is a reduction in the number of grace periods. One way to estimate this is to take the per-second grace period rate and subtract one grace period per two seconds. If the system is idle, this effect might be significant. Thanx, Paul > <idle>-0 [007] d..1. 1113.895470: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1115.669446: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1115.898144: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1117.202833: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1117.900521: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1119.903327: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1120.766864: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1121.909182: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1122.441927: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1123.908911: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1125.868505: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1125.910898: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1127.682837: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1127.913719: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1129.916740: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1130.967052: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1131.919256: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1132.957163: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [000] d..1. 1133.630082: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1133.923053: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1135.927054: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1136.067679: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1137.652294: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1137.932546: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1138.200768: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1139.932573: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1141.167489: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1141.935232: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1143.440538: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle > <idle>-0 [007] d..1. 1143.938560: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle