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:47 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 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.
Can be done. I can wrap the "total bogomips" print part inside the
ARCH_SKIP_SECONDARY_CALIBRATE.

Regards,
Santosh