On 24/07/23 21:18, Frederic Weisbecker wrote:
On Mon, Jul 24, 2023 at 05:55:44PM +0100, Valentin Schneider wrote:
I can make that a 'do {} while ()' instead to force at least one execution of the cmpxchg().
This is only about reducing the race window, right? If we're executing this just as the target CPU is about to enter userspace, we're going to be in racy territory anyway. Regardless, I'm happy to do that change.
Right, it's only about narrowing down the race window. It probably don't matter in practice, but it's one less thing to consider for the brain :-)
Ack
Also, why bothering with handling CONTEXT_IDLE?
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.