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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFwfnT2M1OXzYiy74WCdoRHpKgMby20eqCBe-pEoS6ds-w@mail.gmail.com>
Date:	Tue, 6 Jan 2015 14:33:57 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Pavel Machek <pavel@....cz>,
	Marc Zyngier <marc.zyngier@....com>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Revert 9fc2105aeaaf56b0cf75296a84702d0f9e64437b to fix
 pyaudio (and probably more)

On Mon, Jan 5, 2015 at 10:22 AM, Catalin Marinas
<catalin.marinas@....com> wrote:
>
> If the always constant bogomips is not desirable, we are left with
> having to do a dummy calibration to guess some value to be reported to
> user as BogoMIPS.

Not at all.

Just use whatever counter frequency you use for the delay loop (and
traditionally, you multiply by two, since the *original* bogomips loop
was two instructions).

That's why the bogomips printout has that "500000" value. It's
multiplying by two, and then dividing by a million to get MHz.

That's what bogomips *is*, for chrissake! It's a bogus measure of how
many times you go through the delay loop.

And the delay loop does *not* have to be that "decrement and loop". It
can be "read timer and loop". Since the delay loop is all about
microseconds, your timer had betterr have a frequency in the MHz range
anyway.

On some platforms, it could be the traditional sw-based loop counter
because it's the only thing you have. On others, it could be a CPU
cycle counter. On yet others, it could be a specialized timer counter.
It doesn't matter, all is valid.

What is *not* valid is clearly:

 - removing the bogomips line.

   You can try again in a couple of years. Maybe nobody will notice.
But people *did* notice, and that commit got reverted. End of story,
anybody who argues for removal is simply wrong.

 - making shit up

   Bogomips is a bogus benchmark, but it is *not* a constant number,
and it *does* have to do with the timing loop.

The "making shit up" case is less wrong (pretty much by definition,
since "breaking user space applications" is the most wrong you can
ever be), but you know what? bogomips has a long history of bogosity.
It's integral. It goes back a long time. It has historical
significance. It isn't 0.01 material, but it was certainly added
before 1.0.

.. and it's still a better benchmark than dhrystone.

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