From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wolverine01.qualcomm.com ([199.106.114.254]:59773 "EHLO wolverine01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753348Ab0DVXVK (ORCPT ); Thu, 22 Apr 2010 19:21:10 -0400 Message-ID: <4BD0D9E5.3020606@codeaurora.org> Date: Thu, 22 Apr 2010 16:21:09 -0700 From: Saravana Kannan MIME-Version: 1.0 Subject: Re: CPUfreq - udelay() interaction issues References: <4BCFC3D0.5080904@codeaurora.org> In-Reply-To: <4BCFC3D0.5080904@codeaurora.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-arm-msm-owner@vger.kernel.org List-ID: To: cpufreq , linux-arm-msm , Dave Jones , Venkatesh Pallipadi , Mathieu Desnoyers , Thomas Renninger Resending email to "cc" the maintainers. Maintainers, Any comments? -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