Re: [PATCH] Revert 9fc2105aeaaf56b0cf75296a84702d0f9e64437b to fix pyaudio (and probably more)

[Catalin Marinas]

On 7 January 2015 at 20:53, Russell King - ARM Linux
<linux@xxxxxxxxxxxxxxxx> wrote:
> I think what Linus is trying to tell us is that:
>
> 1. Where the kernel uses a software loop for implementing delays,
>    the kernel bogomips gives us a calibration of that loop.

Fine.

> 2. Where the kernel uses a hardware timer for implementing delays,
>    the kernel bogomips gives us a calibration of that hardware timer.

Fine as well.

> And it doesn't matter whether or not that timer has anything to do with
> the raw CPU speed.

Indeed.

> In other words, bogomips is a statement about the accuracy of the
> internal kernel mechanism being used for delays, nothing more, nothing
> less.

And for whatever reason, some user space program thinks it can read
something meaningful out of this number and use it in user space. But
the consensus is that even if user space is badly implemented, we do
*not* break it. I agree.

> Now, if I understand Linus correctly, what irks him is when someone
> upgrades a kernel on a platform, and some userland breaks.  That's
> something which I've said multiple times I don't have a problem
> agreeing with, and I suspect no one in this thread would disagree
> that this is a serious failing, and one which needs fixing ASAP.

Agree. But I assume you refer to the fact that we removed the BogoMIPS
reporting. It's fine to have it reverted.

> However, if running userland on platform A works, and but it doesn't
> work on platform B.  The breakage may well be due to platform A reporting
> 300 bogomips because it's using the kernel software loop, and platform
> B reporting 6 bogomips because its using a hardware timer, but the CPU
> is actually faster.  However, this is not a kernel problem, and it
> certainly is not a regression.  It's a userspace bug which needs
> userspace to fix.

We need to look back at the point we added timer-based delay about 2.5
years ago. Prior to commit d0a533b18235d362, platform A reported
bogomips 300. After that commit, the *same* platform A (not B),
started reported 6.

Is the above considered user breakage? That's what Nico is trying to
solve. If we are fine with it, than we can close this thread, no
further changes needed.

We can document it as Linus suggests and say that prior to whatever
version we had 2.5 years ago, BogoMIPS was based on a busy loop. In
more recent kernels, it is based on a timer delay. User space should
make use of such information when interpreting BogoMIPS.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/