udelay() too slow by a factor of 2 on Cavium chips

udelay() too slow by a factor of 2 on Cavium chips

[Brian Daniels]

We've noticed that udelay() and related functions are too slow by a
factor of 2 on Cavium CPUs. I did some investigation and it seems to be
related to the fact that Cavium is the only MIPS CPU family that has
ARCH_HAS_READ_CURRENT_TIMER defined to use its hardware cycle counter
(CvmCount) to calibrate loops-per-jiffy. Since udelay() uses lpj to
calculate the number of loops to wait in __delay() it is affected by the
lpj calibration.

On a 600MHz Cavium system running 2.6.33-rc8 with HZ=250 the lpj is
2404728. This results in udelay() passing 601 to __delay() for a 1us
delay which would work if __delay took 1 cycle per loop however it takes
2 cycles giving a delay of 2us.

It seems the easiest way to fix the problem would be to remove the
definition of ARCH_HAS_READ_CURRENT_TIMER for Cavium which would use the
same lpj calibration delay loop as other MIPS CPUs. With this change on
the same 600MHz system lpj is 1196032 which results in udelay() passing
299 to __delay() which would yield close to the desired 1us delay.

I'm not sure what all of the implications would be of effectively
halving lpj on Cavium CPUs or what the rationale was for defining
ARCH_HAS_READ_CURRENT_TIMER for Cavium CPUs in the first place. I'm
hoping someone more informed can take a look at it and propose a fix if
what I've proposed isn't good enough.

Re: udelay() too slow by a factor of 2 on Cavium chips

[David Daney]

On 02/24/2010 05:37 PM, Brian Daniels wrote:
> We've noticed that udelay() and related functions are too slow by a
> factor of 2 on Cavium CPUs. I did some investigation and it seems to be
> related to the fact that Cavium is the only MIPS CPU family that has
> ARCH_HAS_READ_CURRENT_TIMER defined to use its hardware cycle counter
> (CvmCount) to calibrate loops-per-jiffy. Since udelay() uses lpj to
> calculate the number of loops to wait in __delay() it is affected by the
> lpj calibration.
>
> On a 600MHz Cavium system running 2.6.33-rc8 with HZ=250 the lpj is
> 2404728. This results in udelay() passing 601 to __delay() for a 1us
> delay which would work if __delay took 1 cycle per loop however it takes
> 2 cycles giving a delay of 2us.
>
> It seems the easiest way to fix the problem would be to remove the
> definition of ARCH_HAS_READ_CURRENT_TIMER for Cavium which would use the
> same lpj calibration delay loop as other MIPS CPUs. With this change on
> the same 600MHz system lpj is 1196032 which results in udelay() passing
> 299 to __delay() which would yield close to the desired 1us delay.
>
> I'm not sure what all of the implications would be of effectively
> halving lpj on Cavium CPUs or what the rationale was for defining
> ARCH_HAS_READ_CURRENT_TIMER for Cavium CPUs in the first place. I'm
> hoping someone more informed can take a look at it and propose a fix if
> what I've proposed isn't good enough.
>

Thanks for the report.  I will look at it.

David Daney