On 7 January 2015 at 20:53, Russell King - ARM Linux <li...@arm.linux.org.uk> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
