On 12/05/23 16:20, Joel Fernandes wrote: > I think a better approach is not do an anti-CONFIG option and instead do > a shorter parameter "rcutree.lazy=0". If CONFIG_RCU_LAZY is set, then we can > just default to keeping lazy on. I'd like to avoid proliferation of already > large number of RCU config options and more chances of errors. The issue is that we don't want to ship with default on :-) > I also want lazy to be ON for everybody configuring it into the kernel by > default (those who don't want it just set CONFIG_RCU_LAZY=n), this is what This is still the default behavior. And all or nothing approach is not practical. You're telling me if I can't ship with default off, then I must disable it altogether. Adoption will become harder IMHO. > tglx also suggested that's why we made changed of our initial prototypes of > call_rcu_lazy() and instead we made call_rcu() to put everyone on the lazy > train and not add more APIs (thus causing more confusion to kernel > developers). This was a bit painful, but it was worth it. I think implementation details make sense, but orthogonal to the problem of enabling CONFIG_RCU_LAZY=y but still ship with default off. It is a risky change and we want to start staging with default off first. Not allowing this in upstream means I'll either have to resort to keep it disabled, or carry out of tree patch to get what I want. Both of which would be unfortunate. Thanks! -- Qais Yousef
