[PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK to speed-up boot
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
>> 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
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