Haunted by ancient history [LWN.net]

Haunted by ancient history

Posted Jan 8, 2015 20:12 UTC (Thu) by reubenhwk (guest, #75803) [Link] (1 responses)

I'm having trouble envisioning any use-case where somebody would need to know the speed of the processor... Why is anybody using bogomips in code anyway?

Haunted by ancient history

Posted Jan 9, 2015 11:52 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Lazy defaults for quality settings in a game? I'd think it'd be better to just run a series of renders and drop quality until you hit your target though.

Haunted by ancient history

Posted Jan 9, 2015 2:41 UTC (Fri) by mina86 (guest, #68442) [Link] (11 responses)

I say, just print constant 1.

Haunted by ancient history

Posted Jan 9, 2015 13:58 UTC (Fri) by moltonel (guest, #45207) [Link] (10 responses)

+1, but make it configurable. Some software apparently *does* make use of bogomips, and we apparently want to avoid breaking them even more than they broke themselves.

* CONFIG_BOGOMIPS_REAL for software that actually needs it
* CONFIG_BOGOMIPS_FAKE for software that reads it but will still function with a low value
* CONFIG_BOGOMIPS_NONE for modern systems

Prefer none over fake over real, and let users/distributions bug upstream about broken software. Voilà - it'll only take a decade to get rid of bogomips completely.

Haunted by ancient history

Posted Jan 9, 2015 20:20 UTC (Fri) by dlang (guest, #313) [Link] (9 responses)

what is "REAL bogomips"? especially on systems that change the cpu frequency and/or have different cores running at different frequencies?

Haunted by ancient history

Posted Jan 9, 2015 22:28 UTC (Fri) by moltonel (guest, #45207) [Link] (8 responses)

Whatever the definition used to be, how far can you count in 1ms or something. It really doesn't matter. Call it BELIEVABLE or USABLE if you think that REAL gives a false sense of correctness.

The point is that some (buggy but kernel-supported) software will use it to calibrate some kind of performance loop. So try to give them a usable value; if you get within 20% of the ideal value it's good enough. Don't go beyond the call of duty trying to give a "good" value to something that is bogus by design.

That said, I think (as a user) that the kernel's no-breakage stance is too strict. If you're willing to keep using old unmaintained software, you should be ok with using old unmaintained kernels that are still compatible with said software. I'd have been happy to see bogomips disappear from Linux immediately. But if you're not willing to do that today, please at least prepare things so that we can do it in a few years.

Haunted by ancient history

Posted Jan 9, 2015 23:33 UTC (Fri) by dlang (guest, #313) [Link] (3 responses)

> if you get within 20% of the ideal value it's good enough.

you can't get it within 200% of the ideal value, it may not be possible to get it within 2000% of the ideal value. And the ideal value will change from time to time with no notice.

any software the uses delay loops is broken on a multi-user or even multi-application machine, let alone using bogomips to calibrate such loops.

That said, breaking software that's doing the wrong thing still isn't acceptable. Even if the software is maintained, getting the new version into the hands of users can take a LONG time. Rsyslog is very actively maintained and is on v8.6 right now. We still get people asking questions about v3.x, which was out of date in 2006.

Haunted by ancient history

Posted Jan 10, 2015 0:52 UTC (Sat) by moltonel (guest, #45207) [Link] (2 responses)

We may disagree on the maths but we agree on the basic observations; I'm not sure what you're trying to add ?

Since Linus has decreed that bogomips should be kept, we should keep it in the form that applications expect. We all know that that form is completely broken, but that's irrelevant. Apps ask a stupid question, and Linux gives a stupid answer in the name of retrocompatibility. That's what Linus asked for, and I'm not in a position to disagree.

What I *can* suggest is to take measures today so that in many years the compatibility argument gets weak enough to be ignored. Making bogomips configurable is such a measure, a pretty standard deprecation strategy (even if the time between deprecation and removal is huge).

Haunted by ancient history

Posted Jan 10, 2015 2:29 UTC (Sat) by dlang (guest, #313) [Link] (1 responses)

As I read Linus' message, he was saying that some value needed to be there, even if it was known to have n relation to reality (because software broke if it wasn't there to read). In your posts it sounded like you were saying that there needed to be an option to provide a "real" value. That's a much more demanding option than just having some value there.

Haunted by ancient history

Posted Jan 11, 2015 22:56 UTC (Sun) by moltonel (guest, #45207) [Link]

If no program depends on a "real" value then great, just return a constant like "1" and be done with it. I find it unlikely that there isn't a program that uses the value in its logic (as opposed to just displaying it), but I admit I don't have an example to provide.

Haunted by ancient history

Posted Jan 10, 2015 18:01 UTC (Sat) by nix (subscriber, #2304) [Link] (3 responses)

If you're willing to keep using old unmaintained software, you should be ok with using old unmaintained kernels that are still compatible with said software.

It is quite possible for old unmaintained software not to contain security holes and to work perfectly well. Software does not intrinsically rot.

It is not possible for an old unmaintained kernel not to contain security holes (for the simple reason that the kernel is one single piece of software and has holes discovered from time to time).

Thus, your proposal would force people to upgrade to the latest and greatest, no matter how much of their workflows it broke. That's not very nice to the users. (This unthinking attitude that "I use a recent version of everything, therefore so can everyone else" is a large part of what's wrong with the modern Linux world IMNSHO).

Haunted by ancient history

Posted Jan 11, 2015 23:46 UTC (Sun) by moltonel (guest, #45207) [Link] (2 responses)

Just to be clear: I do think that maintaining compatibility is an essential requirement.

But there are various degrees of old, unmaintained, and incompatible. And Linux often takes what looks like a hypocritical decision on what to keep and what to remove. Where's the kernel for my devfs distro ? Can I really run this 15-years old XFree86 on 3.18 ? The "if someone notices" rule is both pragmatic and naïve. there are plenty of kernel-broken software out there. Note that the situation is worse with applications and libraries.

Having a zero-tolerance "no backward-compatibility" rule is very noble until you realize that so much stuff is broken anyway.

I'm doing the opposite of forcing people to upgrade to the latest : I'm telling them to keep running that old kernel if they need to. There are plenty of situations where this is fine. Not all security issues affect everybody. I've got plenty of systems I can't afford to update, so I just put them somewhere where they won't be exposed to threats.

And if that fails, virtualisation is easy nowadays. Bogomips can't have a decent value on most modern hardware, so I'd even have to use an emulator to get my old game working properly. Thankfully, the app that require this treatment and are in comon use should be a rarity.

Not breaking compatibility is important. But folling this rule to the extreme is silly.

http://xkcd.com/1172/

Haunted by ancient history

Posted Jan 12, 2015 3:37 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

Once you start saying that regressions for some people are acceptable if they make things better for more people you very quickly degrade into a very bad situation

different people's estimates of how many are helped by the fix vs hurt by the regression will vary wildly.

you will end up breaking _something_ for people on a regular basis

people remember things that break for them FAR more than they remember new features or speed. You need something way over 10:1 fix:break ratio to begin to have things break even (some people think this is over 100:1)

Linux-kernel development has been there in the past, and it had a reputation for breaking users systems on a regular basis. Avoiding a repeat of this history is why Linus fights so hard against regressions.

I've reported problems with binary-only apps and seen the offending patch reverted within hours. However, if you don't run current upstream kernels, or don't report when things are broken, you can't count on anyone else reporting it either, and so it's possible for the problem to live for a long while. "Enterprise" distros make this worse due to the added lag in getting new kernels out to users, so when a problem is noticed, it make be due to a change that was made upstream years ago. Such problems still need to be reported, and as this case shows, they are taken seriously by Linus and get fixed.

Haunted by ancient history

Posted Jan 15, 2015 1:12 UTC (Thu) by nix (subscriber, #2304) [Link]

people remember things that break for them FAR more than they remember new features or speed. You need something way over 10:1 fix:break ratio to begin to have things break even (some people think this is over 100:1)

Exactly! I was just about to follow up and comment on how a recent SCSI breakage of mine was fixed nice and fast -- but then I realised that that 'recent' breakage was in 2013! But it still *felt* recent, because it broke the boot in a scary fashion.

One nice example of a good recent fix for me was a series of helpful responses, suggestions, and finally a quirk addition when my Simtec Entropy Key started spontaneously failing in 3.16, even though 3.17 had been out for some time and 3.18 was fairly close to release. This was a particular monster to track down because it was timing-related, intermittent, only happened after a reboot, and required physical removal of a USB device to fix. I think I rebooted 180-odd times in the process of bisecting, and had two or three wrong bisection paths due to mistaking bad commits for good ones. I couldn't ask anyone else to do this -- Entropy Keys aren't very common -- and it took me some weeks to find the time to do it, but once it was tracked down, a fix was almost immediate, even though Entropy Keys are not exactly the most crucial hardware ever, and I say that even though my firewall won't boot without its nice juicy random numbers. Now that's the right way to fix bugs! So bravo Johan! :)

Haunted by ancient history

Posted Jan 10, 2015 1:07 UTC (Sat) by moltonel (guest, #45207) [Link]

If the change can go unnoticed (in other words if the value is good enough) you can be sure that some naive programmer will use it for new work. Using bogomips was already "obviously wrong" 10 years ago, and programmers still used it.

If you want naive programmers to notice you need an even wrong-er value like "1" or "not implemented", but that'll raise compatibility red flags. But if those wrong-er values are configurable...