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

[Linus Torvalds]

On Wed, Jan 7, 2015 at 2:42 PM, Nicolas Pitre <nicolas.pitre@xxxxxxxxxx> wrote:
>
> Since when does bogomips mean kernel low-level timer resolution?

Well, effectively since always, even if it wasn't a primary thing. The
primary thing was just the sillyness of it all.

The fact that it always meant low-level timer resolution comes through
clearly in the actual change:

> As Catalin pointed out, the bogomips value went from 800 down to 6 when
> timer based udelay was introduced on ARM for the same piece of hardware.

The very fact that bogomips changed is kind of indicative of what
bogomips _is_, wouldn't you say.

But:

> Is that really what user space is expecting here?

It doesn't matter what user space "expects". User space isn't
conscious, and if it was, we still wouldn't care.

All that matters is whether it *works*.

And in this case, I suspect that pretty much any value actually
happens to fall in that "works" category.

> That's where I don't understand anymore.
>
> If the answer is: "user space should never care because bogomips is
> totally bogus" as some people are claiming then why all the fuss about
> "lying"?

No the answer is "we have no real idea what crazy things user space
might do, and we don't make value judgements on regressions".

User space is filled with insane code, some of it outright *buggy*
code, but users don't care. They just care about "it used to work, and
now it doesn't".

And, as a result, that's all we care about fixing too.

[ Ok, that's not really true.

   Obviously we do care about maintainability and other intrinsic
goals, but to a first approximation the externally visible issues are
much more important than our own intrinsic goals ]

And sometimes those kinds of regressions can end up being unsolvable.

Yes, the #1 rule for the kernel is "no regressions. Ever".

But while that is something I want people to consider a hard rule,
there are some cases where it's just not possible. I mentioned
security issues earlier - we've had cases where we simply could not
support an interface because it turned out to be fundamentally flawed
in a bad way.

Timing-related things can be similar. The whole "it used to work, now
it doesn't" could be an actual race condition - in user space - that
just was practically impossible to hit before on a particular machine,
and then something changed, and now it's easy to hit. There's nothing
we can really do about those kinds of things. It technically *is*
still a regression, it's just not one we can fix.

So in theory, bogomips changing (on the same machine) could indeed be
a regression. It wouldn't even be one of the "unsolvable" kinds,
because while it's timing-related, we *could* fudge the user-visible
scale factor etc. I wouldn't _want_ to, but it's not "fundamentally
unsolvable"

I'm pretty sure that kind of fudging isn't actually necessary in this
case, though.

But that "I'm pretty sure" is not because "people who would depend on
bogomips are crazy and applications using it are fundamentally buggy,
so we don't need to care". Buggy applications that do insane things
still count as regressions.

No, the "pretty sure" is because we know that bogomips varies wildly
between different machines, and any user application that actually
uses the value and is actively bring used clearly *does* work with
different values. It's likely fairly hard to make a real app that does
anything actually useful, and that seriously depends on the exact
bogomips (where "exact" is "within a few orders of magnitude" - not
very exact at all ;).

Sure, it's not impossible, but you *almost* have to actively try to do
something insane. And most user-space insanity is not "actively try to
do something insane" as just due to plain incompetence.

"Never blame on malice that which can be sufficiently explained by stupidity".

                           Linus
--
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/