On Wed, 20 Apr 2022 18:44:00 +0100,
Catalin Marinas <catalin.marinas@xxxxxxx> 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@xxxxxxxxxx>
> > ---
> > 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@xxxxxxx>
>
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
