On Wed, Jan 07, 2015 at 03:34:42PM -0500, Nicolas Pitre wrote: > On Wed, 7 Jan 2015, Linus Torvalds wrote: > > > On Wed, Jan 7, 2015 at 11:00 AM, Nicolas Pitre <nicolas.pi...@linaro.org> > > wrote: > > > > > > 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. > > > > Why? > > > > You'd basically be lying. And it might actually hide real problems. > > If the scaling hides the fact that the timer source cannot do a good > > job at microsecond resolution delays, then it's not just lying, it's > > lying in ways that hide real issues. So why should that kind of > > behavior be encouraged? The actual *real* unscaled resolution of the > > timer is valid and real information. > > I think you are missing something fundamental in this thread.
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. 2. Where the kernel uses a hardware timer for implementing delays, the kernel bogomips gives us a calibration of that hardware timer. And it doesn't matter whether or not that timer has anything to do with the raw CPU speed. In other words, bogomips is a statement about the accuracy of the internal kernel mechanism being used for delays, nothing more, nothing less. 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. 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. Does that make the difference clear? -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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/
