Looks like our emails just crossed each other.
Thomas Renninger wrote:
On Thursday 22 April 2010 11:22:20 pm Saravana Kannan wrote:
Dave, Venkatesh and other maintainers,
Any comments?
From adjust_jiffies in cpufreq.c:
* adjust_jiffies - adjust the system "loops_per_jiffy"
*
* This function alters the system "loops_per_jiffy" for the clock
* speed change. Note that loops_per_jiffy cannot be updated on SMP
* systems as each CPU might be scaled differently. So, use the arch
* per-CPU loops_per_jiffy value wherever possible.
For SMP case adjust_jiffies is just empty.
udelay on x86 uses the per cpu loops_per_jiffy:
cpu_data(raw_smp_processor_id()).loops_per_jiffy
which does not get adjusted via adjust_jiffies()
Yes. That's why one of my questions/assumptions in my prev email was
about adjusting jiffies in SMP case.
So, can I get a confirmation on the following from the maintainers?
* For proper operation in SMP case, CPUfreq core expects the CPUfreq
driver to adjust the per-CPU jiffies.
Without that confirmation, I really can't claim to have found any
issues. Although, if the above is not the expectation, then turning on
CPUfreq should mandate booting up at the highest freq (see next point)
-- which is not realistic.
For me it looks as udelay is always wrong and sleeps too long
on lower frequencies, but I may oversee something.
Not only that, but if the boot up freq is not the highest freq, then
udelay is going to sleep shorter than the requested period on any freq
higher than the boot up freq.
It shouldn't be that hard to test this with a tiny test module
which is measuring real udelay sleep times via tsc reads on a x86 machine
with stable tsc. Doing that in a loop, print out the diff to how long
it should have slept and doing that under lowered freq or whatever bad
circumstances, should show worst cases after some time.
I'm not sure there is a real need to test here. If the maintainers can
confirm that the cpufreq core expects the cpufreq drivers to handle the
jiffy adjusting for SMP cases, then it's clear that there are a few bugs.
Also, for the "context switch issue" (issue 1), it's going to be hard to
produce the exact scenario during testing and we may never hit it, but
it would still be an issue.
Any comments on the "CPU affinity issue"?
Thanks,
Saravana
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
