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

[Russell King - ARM Linux]

On Tue, Jan 18, 2011 at 05:42:22PM +0530, Santosh Shilimkar wrote:
> > -----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.

We should also skip printing the "total bogomips" value too if CPUs were
skipped.