From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752525AbdKTSb4 (ORCPT ); Mon, 20 Nov 2017 13:31:56 -0500 Received: from pandora.armlinux.org.uk ([78.32.30.218]:59360 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752084AbdKTSbz (ORCPT ); Mon, 20 Nov 2017 13:31:55 -0500 Date: Mon, 20 Nov 2017 18:31:26 +0000 From: Russell King - ARM Linux To: Doug Anderson Cc: Nicolas Pitre , Alan Cox , Mason , Thibaud Cornic , Jonathan Austin , Arnd Bergmann , Kevin Hilman , Peter Zijlstra , Stephen Boyd , Michael Turquette , Mark Rutland , Will Deacon , LKML , Steven Rostedt , John Stultz , Boris Brezillon , Thomas Gleixner , Linus Torvalds , Ingo Molnar , Linux ARM , Marc Gonzalez Subject: Re: [RFC] Improving udelay/ndelay on platforms where that is possible Message-ID: <20171120183126.GE31757@n2100.armlinux.org.uk> References: <9a4cfa9d-3940-b7f2-5a4d-59e89af85bb7@sigmadesigns.com> <48c38055-20f7-e565-aa56-74f360e6e3d9@sigmadesigns.com> <20171116163254.GK31757@n2100.armlinux.org.uk> <20171116170527.GL31757@n2100.armlinux.org.uk> <9f678f27-38a0-1dbe-50b9-2d9109c639a9@free.fr> <20171116232206.GM31757@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 20, 2017 at 09:38:46AM -0800, Doug Anderson wrote: > Hi, > > On Thu, Nov 16, 2017 at 3:22 PM, Russell King - ARM Linux > wrote: > > On Thu, Nov 16, 2017 at 02:15:02PM -0800, Doug Anderson wrote: > >> Hi, > >> > >> On Thu, Nov 16, 2017 at 1:05 PM, Marc Gonzalez > >> wrote: > >> > On 16/11/2017 18:05, Russell King - ARM Linux wrote: > >> > > >> >> On Thu, Nov 16, 2017 at 05:42:36PM +0100, Marc Gonzalez wrote: > >> >> > >> >>> Requesting 100 盜 and spinning only 25 盜 is still a problem, > >> >>> don't you agree? > >> >> > >> >> Which is why, as I've said *many* times already, that drivers are written > >> >> with leaway on the delays. > >> > > >> > A delay 75% too short is possible. Roger that. > >> > > >> >> I get the impression that we're just going around in circles, and what > >> >> you're trying to do is to get me to agree with your point of view. > >> >> That's not going to happen, because I know the history over about the > >> >> last /24/ years of kernel development (which is how long I've been > >> >> involved with the kernel.) That's almost a quarter of a century! > >> >> > >> >> I know how things were done years ago (which is relevant because we > >> >> still have support in the kernel for these systems), and I also know the > >> >> history of facilities like cpufreq - I was the one who took the work > >> >> that Erik Mouw and others involved with the LART project, and turned it > >> >> into something a little more generic. The idea of dynamically scaling > >> >> the CPU frequency on ARM SoCs was something that the SoC manufacturer > >> >> had not even considered - it was innovative. > >> >> > >> >> I know that udelay() can return short delays when used in a kernel with > >> >> cpufreq enabled, and I also know that's almost an impossible problem to > >> >> solve without going to a timer-based delay. > >> >> > >> >> So, when you think that sending an email about a udelay() that can be > >> >> 10x shorter might be somehow new information, and might convince people > >> >> that there's a problem, I'm afraid that it isn't really new information. > >> >> The SA1110 cpufreq driver is dated 2001, and carries my copyright, and > >> >> has the ability to make udelay()s 4x shorter or 4x longer depending on > >> >> the direction of change. > >> >> > >> >> We've discussed solutions in the past (probably 10 years ago) about > >> >> this, and what can be done, and the conclusion to that was, as Nicolas > >> >> has said, to switch to using a timer-based delay mechanism where > >> >> possible. Where this is not possible, the platform is stuck with the > >> >> loops based delays, and their inherent variability and inaccuracy. > >> >> > >> >> These platforms have been tested with such a setup over many years. > >> >> They work even with udelay() having this behaviour, because it's a > >> >> known issue and drivers cater for it in ways that I've already covered > >> >> in my many previous emails to you. > >> >> > >> >> These issues are known. They've been known for the last 15 odd years. > >> > > >> > So you've known for umpteen years that fixing loop-based delays is > >> > intractable, yet you wrote: > >> > > >> >> udelay() needs to offer a consistent interface so that drivers know > >> >> what to expect no matter what the implementation is. Making one > >> >> implementation conform to your ideas while leaving the other > >> >> implementations with other expectations is a recipe for bugs. > >> >> > >> >> If you really want to do this, fix the loops_per_jiffy implementation > >> >> as well so that the consistency is maintained. > >> > > >> > In other words, "I'll consider your patch as soon as Hell freezes over". > >> > > >> > Roger that. I'll drop the subject then. > >> > >> Presumably, though, you could introduce a new API like: > >> > >> udelay_atleast() > >> > >> That was guaranteed to delay at least the given number of > >> microseconds. Unlike the current udelay(), the new udelay_atleast() > >> wouldn't really try that hard to get a delay that's approximately the > >> one requested, it would just guarantee not to ever delay _less_ than > >> the amount requested. > > > > I look forward to reviewing your implementation. > > It's unlikely I'll post a patch in the near term since this isn't > presenting me with a big problem right now. Mostly I saw Marc's patch > and thought it would be a good patch to land and I knew this type of > thing had bitten me in the past. > > One happy result of this whole discussion, though, is that you now > sound as if you'll be happy the next time someone brings this up since > you're looking forward to reviewing an implementation. That's a nice > change from the original statement questioning why someone was asking > about this again. :) What I'd be happy with, and what I've always been happy with is what I've stated: either we fix _all_ implementations or none of them. We can't have the situation where some implementations give one expectation and others give something completely different. That's always been my argument against _just_ fixing the timer-based delays and ignoring the rest of the problem. Nothing has changed about my position. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up