> -----Original Message----- > From: linux-arm-kernel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:linux- > arm-kernel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Russell King - > ARM Linux > Sent: Friday, January 21, 2011 10:46 PM > To: Rob Herring > Cc: linux-omap@xxxxxxxxxxxxxxx; Santosh Shilimkar; Linus Walleij; > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK > tospeed-up boot > [...] > > That means cpufreq scaling on SMP is broken then... Why isn't > cpufreq > marked with a !SMP dependence or something similar (eg, depends on > !SMP || CPU_INDEPENDENT_UDELAY)... Maybe it should be. > Actually it's not broken but documented to use arch specific per-cpu lpj with cpufreq scaling. And that update cab be managed by arch specific cpufreq code based on the way CPUs scale. That's how other arch including x86 doing it. And global lpj can be update as well there which is not done at this moment. > > 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. > > As you've shown above, it makes not a blind bit of difference > whether > calibrate_delay() is called... on SMP the loops_per_jiffy will be > wrong > as soon as you start scaling no matter what. > Surely whichever way we should remove the recalibration otherwise every time secondary cpus spend ~ 200 ms there. Russell, How do you like to address this? Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
