From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936836AbdKPVKs (ORCPT ); Thu, 16 Nov 2017 16:10:48 -0500 Received: from smtp4-g21.free.fr ([212.27.42.4]:24760 "EHLO smtp4-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933668AbdKPVKm (ORCPT ); Thu, 16 Nov 2017 16:10:42 -0500 Subject: Re: [RFC] Improving udelay/ndelay on platforms where that is possible To: Russell King - ARM Linux Cc: Nicolas Pitre , Linus Torvalds , Alan Cox , LKML , Linux ARM , Steven Rostedt , Ingo Molnar , Thomas Gleixner , Peter Zijlstra , John Stultz , Douglas Anderson , Mark Rutland , Will Deacon , Jonathan Austin , Arnd Bergmann , Kevin Hilman , Michael Turquette , Stephen Boyd , Boris Brezillon , Thibaud Cornic , Mason References: <11393e07-b042-180c-3bcd-484bf51eada6@sigmadesigns.com> <20171115131351.GE31757@n2100.armlinux.org.uk> <1fa81694-7bd2-564b-e5b9-ae53b9ea6620@sigmadesigns.com> <20171116153625.GJ31757@n2100.armlinux.org.uk> <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> From: Marc Gonzalez Message-ID: <9f678f27-38a0-1dbe-50b9-2d9109c639a9@free.fr> Date: Thu, 16 Nov 2017 22:05:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.1 MIME-Version: 1.0 In-Reply-To: <20171116170527.GL31757@n2100.armlinux.org.uk> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 µs and spinning only 25 µs 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: marc_gonzalez@sigmadesigns.com (Marc Gonzalez) Date: Thu, 16 Nov 2017 22:05:43 +0100 Subject: [RFC] Improving udelay/ndelay on platforms where that is possible In-Reply-To: <20171116170527.GL31757@n2100.armlinux.org.uk> References: <11393e07-b042-180c-3bcd-484bf51eada6@sigmadesigns.com> <20171115131351.GE31757@n2100.armlinux.org.uk> <1fa81694-7bd2-564b-e5b9-ae53b9ea6620@sigmadesigns.com> <20171116153625.GJ31757@n2100.armlinux.org.uk> <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> Message-ID: <9f678f27-38a0-1dbe-50b9-2d9109c639a9@free.fr> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 ?s and spinning only 25 ?s 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.