[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.11.1501071354130.1322@knanqh.ubzr>
Date: Wed, 7 Jan 2015 14:00:48 -0500 (EST)
From: Nicolas Pitre <nicolas.pitre@...aro.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: Catalin Marinas <catalin.marinas@....com>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Pavel Machek <pavel@....cz>,
Marc Zyngier <marc.zyngier@....com>,
kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Revert 9fc2105aeaaf56b0cf75296a84702d0f9e64437b to fix
pyaudio (and probably more)
On Wed, 7 Jan 2015, Linus Torvalds wrote:
> On Wed, Jan 7, 2015 at 10:11 AM, Catalin Marinas
> <catalin.marinas@....com> wrote:
> >
> > I think this makes sense since __delay() expects the number of loops
> > as argument rather than a duration scaled by some factor (based on the
> > generic timer frequency).
>
> Gaah. You guys make no sense at all.
>
> No, __delay() does not expect "number of loops".
>
> It doesn't do that on x86, and it doesn't even do it on arm.
>
> It *literally* does exactly the reverse of what you say it does.
>
> __delay() very much expects a "duration scaled by some factor". The
> factor being "loops_per_jiffy" (ok, so it's a "reverse factor", but
> you get the idea).
>
> And this is very much exactly why bogomips is that "2 *
> loops_per_jiffy * HZ / 1000000".
I think we're all saying more or less the same thing.
The bogomips *reporting* is back on ARM so user space won't break.
We'll make sure it is scaled properly so not to have orders of magnitude
discrepancy whether the timer based or the CPU based loop is used for
the purpose of making people feel good.
Any disagreement?
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists