ACK: [N/U][PATCH 1/1] make lazy RCU a boot time option

[Tim Gardner]

On 12/3/23 1:58 AM, Andrea Righi wrote:
> BugLink: https://bugs.launchpad.net/bugs/2045492
> 
> [Impact]
> 
> With LP: #2023007 we have decided to enable CONFIG_RCU_LAZY in the
> lowlatency kernel to improve power consumption, but this option can
> potentially introduce performance regressions in some cases, due to the
> fact that RCU callbacks are now batched and flushed all at once after a
> timed delay.
> 
> It would be definitely safer to have a way to enable/disable lazy RCUs
> at boot time. In this way we could provide a simple kernel command line
> option that can be used in all those cases where the lowlatency kernel
> is required, but we don't want to risk performance regressions.
> 
> [Test case]
> 
> In this context providing a single test case is not relevant. After
> applying the fix any performance benchmark can be used to evaluate if
> lazy RCU feature should be enabled at boot time or not (according to the
> specific context where the lowlatency kernel is going to be
> used/deployed).
> 
> [Fix]
> 
> Apply this patch to the *generic* kernel:
> https://lore.kernel.org/lkml/20231203011252.233748-1-qyousef@layalina.io/T/#u
> 
> We want to apply this to the generic kernel, not just lowlatency,
> because in this way *all* derivatives will have the possibility to get
> this feature, in case some of them want to enable lazy RCUs (even
> generic itself).
> 
> Then make sure that lowlatency (or any other kernel with
> CONFIG_RCU_LAZY=y) also has CONFIG_RCU_LAZY_DEFAULT_OFF not set (so that
> the previous behavior is not changed).
> 
> [Regression potential]
> 
> We may receive reports of small performance regressions vs power
> consumption regressions, depending on the rcutree.enable_rcu_lazy
> command line option that is used. In such case we should suggest the
> user to test both with lazy RCU disabled or enabled.
> 
> 
Acked-by: Tim Gardner <tim.gardner at canonical.com>
-- 
-----------
Tim Gardner
Canonical, Inc