On Mon, 3 Feb 2025 at 22:49, Ankur Arora <ankur.a.arora@xxxxxxxxxx> wrote: > > Hi, > > This series adds waited variants of the smp_cond_load() primitives: > smp_cond_load_relaxed_timewait(), and smp_cond_load_acquire_timewait(). > > There are two known users for these interfaces: > > - poll_idle() [1] > - resilient queued spinlocks [2] > > For both of these cases we want to wait on a condition but also want > to terminate the wait at some point. > > Now, in theory, that can be worked around by making the time check a > part of the conditional expression provided to smp_cond_load_*(): > > smp_cond_load_relaxed(&cvar, !VAL || time_check()); > > That approach, however, runs into two problems: > > - smp_cond_load_*() only allow waiting on a condition: this might > be okay when we are synchronously spin-waiting on the condition, > but not on architectures where are actually waiting for a store > to a cacheline. > > - this semantic problem becomes a real problem on arm64 if the > event-stream is disabled. That means that there will be no > asynchronous event (the event-stream) that periodically wakes > the waiter, which might lead to an interminable wait if VAL is > never written to. > > This series extends the smp_cond_load_*() interfaces by adding two > arguments: a time-check expression and its associated time limit. > This is sufficient to allow for both a synchronously waited > implementation (like the generic cpu_relax() based loop), or one > where the CPU waits for a store to a cacheline with an out-of-band > timer. > > Any comments appreciated! > Thanks for splitting this and sending it out. +cc bpf@ for visibility (please keep it in cc for subsequent versions). > > [...]
