Re: CPUfreq - udelay() interaction issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dave, Venkatesh and other maintainers,

Any comments?

Thanks,
Saravana

Saravana Kannan wrote:
Hi,

I think there are a couple of issues with cpufreq and udelay interaction. But that's based on my understanding of cpufreq. I have worked with it for sometime now, so hopefully I not completely wrong. So, I will list my assumptions and what I think is/are the issue(s) and their solutions.

Please correct me if I'm wrong and let me know what you think.

Assumptions:
============
* Let's assume ondemand governor is being used.
* Ondemand uses one timer per core and they have CPU affinity set.
* For SMP, CPUfreq core expects the CPUfreq driver to adjust the per-CPU jiffies. * P1 indicates for lower CPU perfomance levels and P2 indicates a much higher CPU pref level (say 10 times faster).

Issue 1: UP (non-SMP) scenario
==============================

This issue is also present for SMP case, but I don't want to complicate this example with it. For future reference in this thread, let's call this "Context switch issue".

Steps:
- CPU running at P1
- Driver context calls udelay
- udelay does loop calculation and starts looping
- Context switches to ondemand gov timer function
- Ondemand gov changes CPU to P2
- Context switches back to Driver context
- udelay does a delay that's 10 times shorter.

The last point is obviously a bad thing. I'm more concerned about ARM arch for the moment, but considering x86 takes a max of 20ms (20000us) for udelay, the above scenario looks very possible.

Is there anything I missed that prevents this from happening?

If this really is an issue, then one solution is to make cpufreq defer the freq change if some flag indicates that udelay is active. Basically, some kind of r/w semaphore or spinlock.

Does this sound like a reasonable solution?

Issue 2: SMP scenario
=====================

For future reference in this thread, let's call this "CPU affinity issue".

Steps:
- CPU0 running at P1
- CPU1 running at P2
- Driver context calls udelay in CPU0
- udelay does loop calculation and starts looping
- Driver context/thread is moved from CPU0 to CPU1
- udelay does a delay that's 10 times shorter.

Again, the last point is obviously a bad thing. Am I missing anything here too? Again, I care more about ARM, but x86 (which a lot more people might care about) also seems to be broken if it doesn't use the TSC method for the delay.

Assuming we fix Issue 1 (or it's not present) I think an ideal solution for this issue is to do something like:

udelay(us)
{
   set cpu affinity to current CPU;
   Do the usual udelay code;
   restore cpu affinity status;
}

Does this sound like a reasonable solution?

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

[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux