On 25/07/23 13:22, Frederic Weisbecker wrote: > On Tue, Jul 25, 2023 at 11:10:31AM +0100, Valentin Schneider wrote: >> I have reasons! I just swept them under the rug and didn't mention them :D >> Also looking at the config dependencies again I got it wrong, but >> nevertheless that means I get to ramble about it. >> >> With NO_HZ_IDLE, we get CONTEXT_TRACKING_IDLE, so we get these >> transitions: >> >> ct_idle_enter() >> ct_kernel_exit() >> ct_state_inc_clear_work() >> >> ct_idle_exit() >> ct_kernel_enter() >> ct_work_flush() >> >> Now, if we just make CONTEXT_TRACKING_WORK depend on CONTEXT_TRACKING_IDLE >> rather than CONTEXT_TRACKING_USER, we get to leverage the IPI deferral for >> NO_HZ_IDLE kernels - in other words, we get to keep idle CPUs idle longer. >> >> It's a completely different argument than reducing interference for >> NOHZ_FULL userspace applications and I should have at the very least >> mentioned it in the cover letter, but it's the exact same backing >> mechanism. >> >> Looking at it again, I'll probably make the CONTEXT_IDLE thing a separate >> patch with a proper changelog. > > Ok should that be a seperate Kconfig? This indeed can bring power improvement > but at the cost of more overhead from the sender. A balance to be measured... Yep agreed, I'll make that an optional config.
