> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+leoli=freescale@lists.ozlabs.org] On Behalf Of David Laight
> Sent: Monday, June 26, 2017 10:55 AM
> To: 'Karim Eshapa' ; o...@buserror.net
> Cc: Roy Pledge ; linux-ker...@vger.kernel.org;
> Claudiu Manoil ; colin.k...@canonical.com;
> linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org
> Subject: RE: [PATCH] soc/qman: Sleep instead of stuck hacking jiffies.
>
> From: Karim Eshapa
> > Sent: 25 June 2017 16:14
> > Use msleep() instead of stucking with
> > long delay will be more efficient.
> ...
> > --- a/drivers/soc/fsl/qbman/qman.c
> > +++ b/drivers/soc/fsl/qbman/qman.c
> > @@ -1084,11 +1084,7 @@ static int drain_mr_fqrni(struct qm_portal *p)
> > * entries well before the ring has been fully consumed, so
> > * we're being *really* paranoid here.
> > */
> > - u64 now, then = jiffies;
> > -
> > - do {
> > - now = jiffies;
> > - } while ((then + 1) > now);
> > + msleep(1);
> ...
> How is that in any way equivalent?
> If HZ is 1000 the old code loops for 10 seconds.
> If HZ is 250 (common for some distros) it loops for 40 seconds.
>
> Clearly both are horrid, but it isn't at all clear that a 1ms sleep is
> performing
> the same job.
>
> My guess is that this code is never called, and broken if actually called.
It was indeed broken. The intent was to wait for 1 cycles but mistakenly
coded as 1 jiffies. I think we choose 1ms as it is not too long and almost
guarantees the 1 cycles delay.
Regards,
Leo