Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756713Ab3CQXI3 (ORCPT ); Sun, 17 Mar 2013 19:08:29 -0400 Received: from caramon.arm.linux.org.uk ([78.32.30.218]:37318 "EHLO caramon.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755698Ab3CQXI2 (ORCPT ); Sun, 17 Mar 2013 19:08:28 -0400 Date: Sun, 17 Mar 2013 23:08:12 +0000 From: Russell King - ARM Linux To: Will Deacon Cc: chpoph , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" , Viresh Kumar , Nicolas Pitre , Liviu Dudau , Greg Kroah-Hartman Subject: Re: udelay function delays the wrong time interval in multiprocessor system, if ARCH_HAS_READ_CURRENT_TIMER is not defined and on current timer is used. Message-ID: <20130317230812.GE4977@n2100.arm.linux.org.uk> References: <20130315181449.GX4977@n2100.arm.linux.org.uk> <20130317200543.GA20174@mudshark.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130317200543.GA20174@mudshark.cambridge.arm.com> User-Agent: Mutt/1.5.19 (2009-01-05) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1544 Lines: 31 On Sun, Mar 17, 2013 at 08:05:43PM +0000, Will Deacon wrote: > On Sat, Mar 16, 2013 at 03:32:43AM +0000, chpoph wrote: > > On Sat, Mar 16, 2013 at 2:14 AM, Russell King - ARM Linux > > wrote: > > > We don't support different CPUs running at different frequencies with > > > the delay loop. Sorry. > > > > Does it means that a timer-based delay implementation must be used to > > get an accurate delay in SMP. I think it should print a warning > > message if the CPU delay loop is used in SMP. In my system, the wrong > > delay interval fluctuated with CPU frequencies caused a control > > problem. > > I've been playing around with loops_per_jiffy recently, in an attempt to > clean up the cpufreq scaling code so that the SMP-ness is in core code, > rather than being duplicated by every architecture: > > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git lpj > > With those changes, it's pretty easy to get different delays depending on > the current CPU, but it would require preempt_{enable,disable} calls around > the delay, which I haven't convinced myself about. Exactly, and that's why I said what I said. If you start doing that, then you might as well turn kernel preemption off altogether, because the delays will impact your system latency. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/