[RFC] Improving udelay/ndelay on platforms where that is possible
From: Pavel Machek <hidden>
Date: 2017-12-07 12:31:39
Also in:
lkml
Hi!
On Wed, Nov 1, 2017 at 2:26 AM, Russell King - ARM Linux [off-list ref] wrote:quoted
On Tue, Oct 31, 2017 at 05:23:19PM -0700, Doug Anderson wrote:quoted
Hi, On Tue, Oct 31, 2017 at 10:45 AM, Linus Torvalds [off-list ref] wrote:quoted
So I'm very much open to udelay improvements, and if somebody sends patches for particular platforms to do particularly well on that platform, I think we should merge them. But ...If I'm reading this all correctly, this sounds like you'd be willing to merge <https://patchwork.kernel.org/patch/9429841/>. This makes udelay() guaranteed not to underrun on arm32 platforms.That's a mis-representation again. It stops a timer-based udelay() possibly underrunning by one tick if we are close to the start of a count increment. However, it does nothing for the loops_per_jiffy udelay(), which can still underrun. My argument against merging that patch is that with it merged, we get (as you say) a udelay() that doesn't underrun _when using a timer_ but when we end up using the loops_per_jiffy udelay(), we're back to the old problem. My opinion is that's bad, because it encourages people to write drivers that rely on udelay() having "good" behaviour, which it is not guaranteed to have. So, they'll specify a delay period of exactly what they want, and their drivers will then fail when running on systems that aren't using a timer-based udelay().IMHO the current udelay is broken in an off-by-one way and it's easy to fix. Intentionally leaving a bug in the code seems silly. This seems to by what Linus is saying with his statement that "(a) platform code could try to make their udelay/ndelay() be as good as it can be on a particular platform". So no matter the rest of the discussions, we should land that. If you disagree then I'm happy to re-post that patch straight to Linus later this week since it sounds as if he'd take it.
Did this get fixed in any way? Russell having crazy arguments for keeping kernel buggy should not be good enough reason to keep the bugs... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html