On Thu, Oct 17, 2024 at 09:56:13AM -0700, Christoph Lameter (Ampere) wrote: > On Wed, 16 Oct 2024, Catalin Marinas wrote: > > The behaviour above is slightly different from the current poll_idle() > > implementation. The above is more like poll every timeout period rather > > than continuously poll until either the need_resched() condition is true > > _or_ the timeout expired. From Ankur's email, an IPI may not happen so > > we don't have any guarantee that WFET will wake up before the timeout. > > The only way for WFE/WFET to wake up on need_resched() is to use LDXR to > > arm the exclusive monitor. That's what smp_cond_load_relaxed() does. > > Sorry no. The IPI will cause the WFE to continue immediately and not wait > till the end of the timeout period. *If* there is an IPI. The scheduler is not really my area but some functions like wake_up_idle_cpu() seem to elide the IPI if TIF_NR_POLLING is set. But even if we had an IPI, it still feels like abusing the semantics of smp_cond_load_relaxed() when relying on it to increment a variable in the condition check as a result of some unrelated wake-up event. This API is meant to wait for a condition on a single variable. It cannot wait on multiple variables and especially not one it updates itself (even if it happens to work on arm64 under certain conditions). My strong preference would be to revive the smp_cond_load_timeout() proposal from Ankur earlier in the year. -- Catalin
