Why call calibrate_delay() in smp.c: secondary_start_kernel()

On Tue, Jan 18, 2011 at 03:46:54PM +0530, Santosh Shilimkar wrote:

I did send a patch on the same some time back but the conclusion
was we still need to have calibration.

Have one more patch do deal with it so that platform can choose
if they like to skip. My mailer might screw the patch hence attaching
the same

Actually, the secondary cores probably get a far more accurate lpj
than the primary core as they don't have the interference from the
timer interrupt.  So - if we care - we probably want to update the
primary lpj with the secondary's calibration value at boot.

On the measurements I've made a couple of weeks ago, the lpj value
can be .7% too slow, resulting in udelay() giving shorter than
requested delays.  I asked Linus about that, and he's happy with
that figure.

So the myth which floats around on various lists about udelay() giving
at least the requested delay is just that - a myth.  It has always
given _approximately_ the requested delay on all architectures with
software loop based implementations (as well as, according to Linus,
some x86 tsc implementations of udelay.)