Re: [PATCH 3/4] arm64: barrier: Add smp_cond_load_relaxed_timewait()

Ankur Arora
2025-03-06T07:59:50Z

Catalin Marinas <catalin.marinas@arm.com> writes:

> On Mon, Feb 03, 2025 at 01:49:10PM -0800, Ankur Arora wrote:
>> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
>> index 1ca947d5c939..25721275a5a2 100644
>> --- a/arch/arm64/include/asm/barrier.h
>> +++ b/arch/arm64/include/asm/barrier.h
>> @@ -216,6 +216,44 @@ do { \
>> (typeof(*ptr))VAL; \
>> })
>>
>> +#define __smp_cond_load_relaxed_timewait(ptr, cond_expr, \
>> + time_expr_ns, time_limit_ns) \
>> +({ \
>> + typeof(ptr) __PTR = (ptr); \
>> + __unqual_scalar_typeof(*ptr) VAL; \
>> + for (;;) { \
>> + VAL = READ_ONCE(*__PTR); \
>> + if (cond_expr) \
>> + break; \
>> + __cmpwait_relaxed(__PTR, VAL); \
>> + if ((time_expr_ns) >= (time_limit_ns)) \
>> + break; \
>> + } \
>> + (typeof(*ptr))VAL; \
>> +})
>
> Rename this to something like *_evstrm as this doesn't really work
> unless we have the event stream.

Ack.

> Another one would be *_wfet.

Hadn't sent out the WFET version yet.

Did you mean that this should be *_evtstrm or *_wfet?

>> +
>> +/*
>> + * For the unlikely case that the event-stream is unavailable,
>> + * ward off the possibility of waiting forever by falling back
>> + * to the generic spin-wait.
>> + */
>> +#define smp_cond_load_relaxed_timewait(ptr, cond_expr, \
>> + time_expr_ns, time_limit_ns) \
>> +({ \
>> + __unqual_scalar_typeof(*ptr) _val; \
>> + int __wfe = arch_timer_evtstrm_available(); \
>
> This should be a bool.

Yeah. Will fix.

>> + \
>> + if (likely(__wfe)) \
>> + _val = __smp_cond_load_relaxed_timewait(ptr, cond_expr, \
>> + time_expr_ns, \
>> + time_limit_ns); \
>> + else \
>> + _val = __smp_cond_load_relaxed_spinwait(ptr, cond_expr, \
>> + time_expr_ns, \
>> + time_limit_ns); \
>> + (typeof(*ptr))_val; \
>> +})
>
> Not sure there's much to say here, this depends on the actual interface
> introduced by patch 1. If we make some statements about granularity of
> some time_cond_expr check, we'll have to take that into account.

Agreed.

Thanks for the review!

--
ankur