From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cantor.suse.de ([195.135.220.2]:35436 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753864Ab0DVXSZ convert rfc822-to-8bit (ORCPT ); Thu, 22 Apr 2010 19:18:25 -0400 From: Thomas Renninger Subject: Re: CPUfreq - udelay() interaction issues Date: Fri, 23 Apr 2010 01:18:31 +0200 References: <4BCFC3D0.5080904@codeaurora.org> <4BD0BE0C.3010709@codeaurora.org> In-Reply-To: <4BD0BE0C.3010709@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline Message-Id: <201004230118.32147.trenn@suse.de> Sender: linux-arm-msm-owner@vger.kernel.org List-ID: To: Saravana Kannan Cc: cpufreq , linux-arm-msm 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() For me it looks as udelay is always wrong and sleeps too long on lower frequencies, but I may oversee something. 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. Thomas