[PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK to speed-up boot

Rob Herring robherring2 at gmail.com
Fri Jan 21 10:00:04 EST 2011


On 01/21/2011 07:43 AM, Santosh Shilimkar wrote:
>> -----Original Message-----
>> From: Rob Herring [mailto:robherring2 at gmail.com]
>> Sent: Thursday, January 20, 2011 10:05 PM
>> To: Santosh Shilimkar
>> Cc: linux-arm-kernel at lists.infradead.org; Russell King; linux-
>> omap at vger.kernel.org; Linus Walleij
>> Subject: Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK
>> to speed-up boot
> [..]
>>>> There's already one way to do this with pre-calculated lpj.
>>> How about the hot-plug path? This is not for just boot.
>> The path is the same for hotplug and secondary boot, so yes for
>> both.
>> Plus you get the added benefit of speeding up the primary core boot
>> as well.
> No 'preset_lpj' will not work for the hotplug path when
> cpufreq is active. It just useful only for boot in
> its current form.

Why? If preset_lpj is non-zero, calibrate_delay will effectively be 
skipped which is the same thing your patch does.

This is the cpfreq loops_per_jiffy adjustment function for SMP:

static inline void adjust_jiffies(unsigned long val, struct 
cpufreq_freqs *ci)

And delay.S uses the global loops_per_jiffy, not the per cpu value. The 
only place I see the per cpu value get used is /proc/cpuinfo.

Consider the following sequence:

- scale down the cpu freq
- hot unplug a core
- hot plug a core
   - calls calibrate_delay and update the global loops_per_jiffy
- scale up the cpu freq
- udelay time is now much too short!!!

So for that reason, I would just remove calibrate_delay unconditionally. 
Better to have the 1% inaccuracy and longer delays at low frequency than 
to have too short of a delay at high freq.


More information about the linux-arm-kernel mailing list