About the accuracy of delay loop

About the accuracy of delay loop

[Jamie Huang]

Hi, all.
	I have a question about the commit
	d0a533b18235d36206b9b422efadb7cee444dfdb ARM: 7452/1: delay:
allow timer-based delay implementation to be selected.

	Recently, I found the BogoMIPS info of kernel start-up log is
	not correct.The correct info is as follows:

	Calibrating delay loop... 719.25 BogoMIPS (lpj=3596288)

	But, after the patch above, the info changed as follows:

	Calibrating delay loop... 478.41 BogoMIPS (lpj=2392064)

	I find the difference from assembly code.
	Before the patch:
	  __delay(loops_per_jiffy);
             c002bcf0:       e50b3034   str r3, [fp, #-52]  ; 0x34
             c002bcf4:       e50b2030   str r2, [fp, #-48]  ; 0x30
             c002bcf8:       eb06ddd8   bl c01e3460 <__delay>

	After the patch:
          __delay(loops_per_jiffy);
             c04add08:       e5932000   ldr r2, [r3]
             c04add0c:       e50b105c   str r1, [fp, #-92]  ; 0x5c
             c04add10:       e50b3060   str r3, [fp, #-96]  ; 0x60
             c04add14:       e50bc064   str ip, [fp, #-100] ; 0x64
             c04add18:       e12fff32   blx r2

 	There are two additional instructions, and these will
 	influence calibration of delay loop. I also worry that this
 	new implementation will influence the accuracy of udelay. Does
 	any one know this problem?

About the accuracy of delay loop

[Jisheng Zhang]

Hi,

On Wed, 10 Aug 2016 15:24:56 +0800 Jamie Huang wrote:

> Hi, all.
> 	I have a question about the commit
> 	d0a533b18235d36206b9b422efadb7cee444dfdb ARM: 7452/1: delay:
> allow timer-based delay implementation to be selected.
> 
> 	Recently, I found the BogoMIPS info of kernel start-up log is
> 	not correct.The correct info is as follows:
> 
> 	Calibrating delay loop... 719.25 BogoMIPS (lpj=3596288)
> 
> 	But, after the patch above, the info changed as follows:
> 
> 	Calibrating delay loop... 478.41 BogoMIPS (lpj=2392064)
> 
> 	I find the difference from assembly code.
> 	Before the patch:
> 	  __delay(loops_per_jiffy);
>              c002bcf0:       e50b3034   str r3, [fp, #-52]  ; 0x34
>              c002bcf4:       e50b2030   str r2, [fp, #-48]  ; 0x30
>              c002bcf8:       eb06ddd8   bl c01e3460 <__delay>
> 
> 	After the patch:
>           __delay(loops_per_jiffy);
>              c04add08:       e5932000   ldr r2, [r3]
>              c04add0c:       e50b105c   str r1, [fp, #-92]  ; 0x5c
>              c04add10:       e50b3060   str r3, [fp, #-96]  ; 0x60
>              c04add14:       e50bc064   str ip, [fp, #-100] ; 0x64
>              c04add18:       e12fff32   blx r2
> 
>  	There are two additional instructions, and these will
>  	influence calibration of delay loop. I also worry that this
>  	new implementation will influence the accuracy of udelay. Does

Per my understanding, udelay is never ensured "accurate", it only ensures
that it at least delays as required.

If udelay is timer-based, then it could gives more accuracy.

Thanks,
Jisheng

>  	any one know this problem?
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

About the accuracy of delay loop

[Jamie Huang]

On Wed, 10 Aug 2016 15:34:29 +0800
Jisheng Zhang <jszhang@marvell.com> wrote:

> Hi,
> 
> On Wed, 10 Aug 2016 15:24:56 +0800 Jamie Huang wrote:
> 
> > Hi, all.
> > 	I have a question about the commit
> > 	d0a533b18235d36206b9b422efadb7cee444dfdb ARM: 7452/1: delay:
> > allow timer-based delay implementation to be selected.
> > 
> > 	Recently, I found the BogoMIPS info of kernel start-up log
> > is not correct.The correct info is as follows:
> > 
> > 	Calibrating delay loop... 719.25 BogoMIPS (lpj=3596288)
> > 
> > 	But, after the patch above, the info changed as follows:
> > 
> > 	Calibrating delay loop... 478.41 BogoMIPS (lpj=2392064)
> > 
> > 	I find the difference from assembly code.
> > 	Before the patch:
> > 	  __delay(loops_per_jiffy);
> >              c002bcf0:       e50b3034   str r3, [fp, #-52]  ; 0x34
> >              c002bcf4:       e50b2030   str r2, [fp, #-48]  ; 0x30
> >              c002bcf8:       eb06ddd8   bl c01e3460 <__delay>
> > 
> > 	After the patch:
> >           __delay(loops_per_jiffy);
> >              c04add08:       e5932000   ldr r2, [r3]
> >              c04add0c:       e50b105c   str r1, [fp, #-92]  ; 0x5c
> >              c04add10:       e50b3060   str r3, [fp, #-96]  ; 0x60
> >              c04add14:       e50bc064   str ip, [fp, #-100] ; 0x64
> >              c04add18:       e12fff32   blx r2
> > 
> >  	There are two additional instructions, and these will
> >  	influence calibration of delay loop. I also worry that this
> >  	new implementation will influence the accuracy of udelay.
> > Does  
> 
> Per my understanding, udelay is never ensured "accurate", it only
> ensures that it at least delays as required.
> 
> If udelay is timer-based, then it could gives more accuracy.
> 
> Thanks,
> Jisheng
> 
> >  	any one know this problem?
> > 
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel  
> 

Thank you for reply. But the users may be confused because of the
different results. You mean there is no need to worry about it? 

About the accuracy of delay loop

[Willy Tarreau]

On Wed, Aug 10, 2016 at 10:59:39PM +0800, Jamie Huang wrote:
> Thank you for reply. But the users may be confused because of the
> different results. You mean there is no need to worry about it? 

The bogomips are already a bogus measure. I've been used to see different
values for kernels running in ARM mode versus Thumb2 mode on the same machine,
likely due to different optimizations. What matters is that the LPJ value is
correct for the executed loop so that udelay calculation is accurate enough.
Here everything's OK.

Willy

About the accuracy of delay loop

[Russell King - ARM Linux]

On Wed, Aug 10, 2016 at 03:34:29PM +0800, Jisheng Zhang wrote:
> Per my understanding, udelay is never ensured "accurate", it only ensures
> that it at least delays as required.

... which is inaccurate.  udelay() offers no such guarantee.
udelay() gives you an _approximate_ delay, and when it is based
on loops_per_jiffy, it will inevitably be slightly shorter than
requested.

This is because of the calibration mechanism.  loops_per_jiffy is
calculated as the number of loops between two subsequent timer
interrupts - so it's missing the number of loops that would have
been run had the timer interrupt not happened.

To put it another way:

t(loops) = t(timer_interrupt_period) - t(timer_irq_function)

So, loops_per_jiffy is always going to be less than the ideal
number, which means udelay() will always be slightly short.

It's not desired to "fix" this.

Things also go wrong if you have cpufreq, and the CPU clock
frequency changes mid-delay - and that can make the resulting
delay either longer or shorter.  Most platforms using cpufreq
should be using a timer to implement udelay() to avoid this.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.