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: <CAHkRjk5EAUvdR5ED_M=dB+5yu3RtZLgo_aighUrozovHKnOp=w@mail.gmail.com>
Date:	Mon, 5 Jan 2015 18:22:01 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	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)

On 5 January 2015 at 14:22, One Thousand Gnomes
<gnomes@...rguk.ukuu.org.uk> wrote:
>> 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.

It's not that simple. The CPU frequency and the timer frequency are
independent. One SoC may have 6MHz timer, another SoC with a similar
CPU frequency may use a 24MHz timer (or maybe a much smaller one). So
a fudge factor is not really any better than choosing a constant
bogomips value at build time (say 2000).

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. Even if we do this, on modern ARM processors it
rarely matches the CPU frequency, only on older/simpler CPUs. With
newer ones, the simple two instructions loop is never 2 cycles (it may
even differ on the same CPU depending on the kernel build, e.g. code
alignment affecting the branch prediction; I recall on ARM11MPCore the
average was half-cycle multiple because the loop took different number
of cycles on consecutive iterations).

(I'm not debating whether we should fix this problem or not, just
trying to find the right solution; reverting the original patch
doesn't entirely fix newer CPUs)

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