Re: CPUfreq - udelay() interaction issues

[Saravana Kannan <skannan@codeaurora.org>]

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