Re: CPUfreq - udelay() interaction issues

[Saravana Kannan <skannan@codeaurora.org>]

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