Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 12 Jan 2011 13:19:49 -0800 | Subject | Re: Bug: loops_per_jiffy based udelay() mostly shorter than requested |
| |
On Sun, Jan 9, 2011 at 9:08 AM, Russell King <rmk@arm.linux.org.uk> wrote: > > Any suggestions or thoughts, or should we not care too much if udelay() > produces slightly shorter than desired delays? Or am I doing something > horribly wrong in the ARM code?
Judging by the numbers you quote, I would definitely put this in the "don't care too much".
If it's about 1% off, it's all fine. If somebody picked a delay value that is so sensitive to small errors in the delay that they notice that - or even notice something like 5% - then they have picked too short of a delay.
udelay() was never really meant to be some kind of precision instrument. Especially with CPU's running at different frequencies, we've historically had some rather wild fluctuation. The traditional busy loop ends up being affected not just by interrupts, but also by things like cache alignment (we used to inline it), and then later the TSC-based one obviously depended on TSC's being stable (which they weren't for a while).
So historically, we've seen udelay() being _really_ off (ie 50% off etc), I wouldn't worry about things in the 1% range.
Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |