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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 5 Jan 2015 14:22:06 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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)

> Yes, x86 has the bogomips thing, and it switched to using a TSC.  I'm
> willing to bet that on x86, the reported bogomips value is pretty similar
> whether it's using the TSC or whether it's using a software timing loop.

Roughly yes. It's a completely dumb number anyway because any loop timing
based number is bogus on any modern x86. Utterly bogus. However its
armwavingly sufficient that software doesn't break (not that any x86
software I know of does anything but print the number for the user so
they can copy it to tweet about how neat their new PC is).

PC people do keep filing bugs about x86 CPU clock numbers being wrong, we
just close them all. Clock rate itself is a bit of a meaningless concept
nowdays.

> This is not the case on ARM.  Here's an example where we use a hardware
> timer for the delay loop:
> 
> Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=12000)
> 
> which is nowhere near the precision of the CPU clock rate.  So, when
> we have a hardware timer based delay implementation, the bogomips
> value which the kernel has access to (and thus the loops_per_jiffy
> value) is totally ... bogus.

So multiply it by a fudge factor so it looks similar and in proportion.

> If we want to take note of the "screenfulls of users reporting problems"
> then we need a much better solution than a simple revert, because right
> now, the simple revert makes machines with GHz clock frequencies look
> slower than the old 1990s 26-bit ARM technology.

That's a marketing problem not a technical one 8)

You actually have the reverse problem to consider. Who can quantify
how many modern ARM apps actually check for Bogomips and then set policy
according to its presence/absence. Reverting a 2013 change may actually
break a load of software that has been fixed or deals with the real world
properly. Pavel doing a random arbitrary long term revert without any
planning is at least as stupid as ignoring it.

What I don't understand here is why it was removed for platforms where it
was meaningful. Surely that's not needed and antiques running antique
userspace would continue to be happy with numbers valid for that era ?

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