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

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

quoted

quoted

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

quoted

quoted

quoted

I did send a patch on the same some time back but the

conclusion

quoted

quoted

quoted

was we still need to have calibration.

Have one more patch do deal with it so that platform can

choose

quoted

quoted

quoted

if they like to skip. My mailer might screw the patch hence

attaching

quoted

the same

Actually, the secondary cores probably get a far more accurate

lpj

quoted

quoted

than the primary core as they don't have the interference from

the

quoted

quoted

timer interrupt.  So - if we care - we probably want to update

the

quoted

quoted

primary lpj with the secondary's calibration value at boot.

On the measurements I've made a couple of weeks ago, the lpj

value

quoted

quoted

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

quoted

quoted

given _approximately_ the requested delay on all architectures

with

quoted

quoted

software loop based implementations (as well as, according to

Linus,

quoted

quoted

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