Re: [PATCH v2 10/10] arm64: Use WFxT for __delay() when possible

[Marc Zyngier <maz@kernel.org>]

On Wed, 20 Apr 2022 18:44:00 +0100,
Catalin Marinas <catalin.marinas@arm.com> wrote:
> 
> On Tue, Apr 19, 2022 at 07:27:55PM +0100, Marc Zyngier wrote:
> > Marginally optimise __delay() by using a WFIT/WFET sequence.
> > It probably is a win if no interrupt fires during the delay.
> > 
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  arch/arm64/lib/delay.c | 12 +++++++++++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c
> > index 1688af0a4c97..5b7890139bc2 100644
> > --- a/arch/arm64/lib/delay.c
> > +++ b/arch/arm64/lib/delay.c
> > @@ -27,7 +27,17 @@ void __delay(unsigned long cycles)
> >  {
> >  	cycles_t start = get_cycles();
> >  
> > -	if (arch_timer_evtstrm_available()) {
> > +	if (cpus_have_const_cap(ARM64_HAS_WFXT)) {
> > +		u64 end = start + cycles;
> > +
> > +		/*
> > +		 * Start with WFIT. If an interrupt makes us resume
> > +		 * early, use a WFET loop to complete the delay.
> > +		 */
> > +		wfit(end);
> > +		while ((get_cycles() - start) < cycles)
> > +			wfet(end);
> 
> Do you use WFET here as a pending interrupt would cause WFIT to complete
> immediately?

Yes, that's the idea. Even if a pending interrupt is not immediately
present, it could come halfway through, shortening the delay, and
making WFIT useless until the interrupt is acknowledged.

I would have loved for WFIT to return a status indicating whether the
wakeup was for a pending interrupt or for another reason (such as
reaching the timeout), but apparently it was too much to ask... Maybe
in ARMv11!  ;-)

> 
> > +	} else 	if (arch_timer_evtstrm_available()) {
> 
> Nit: two spaces between else and if ;).

I'll make sure to fix this! ;-)

> 
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> 

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.