From mboxrd@z Thu Jan  1 00:00:00 1970
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
Date: Tue, 18 Jan 2011 17:55:13 +0530
Subject: Why call calibrate_delay() in smp.c: secondary_start_kernel()
In-Reply-To: <20110118121650.GC9719@n2100.arm.linux.org.uk>
References: <4D3552C2.3020101@stericsson.com>
	<ebe9b3d6a0cc160cd46a97ae05b72119@mail.gmail.com>
	<20110118113111.GA9719@n2100.arm.linux.org.uk>
	<eadb9f7e95a290b415baaa1d35547528@mail.gmail.com>
	<20110118121650.GC9719@n2100.arm.linux.org.uk>
Message-ID: <9f7cc4850e8b0c10e77db7739fb72f96@mail.gmail.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

> -----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