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

[Santosh Shilimkar]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Tuesday, January 18, 2011 5:01 PM
> To: Santosh Shilimkar
> Cc: Jonas Aaberg; linux-arm-kernel at lists.infradead.org;
> STEricsson_nomadik_linux
> Subject: Re: 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.)

Ok. Since the udelay() accuracy is acceptable now, what you think
of my latest patch.

It does help for the archs which are ok to skip the calibration .
And since it's configurable with the proposed patch,
the default kernel behavior is maintained if the option isn't
selected.

Regards,
Santosh