linux-kernel - Re: [PATCH 5/5 v2] ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram

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]

Date:	Fri, 9 Dec 2011 11:00:01 +0100
From:	Janusz Krzysztofik <jkrzyszt@....icnet.pl>
To:	"Russell King - ARM Linux" <linux@....linux.org.uk>
Cc:	Tony Lindgren <tony@...mide.com>, Paul Walmsley <paul@...an.com>,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5 v2] ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram

On Friday 09 of December 2011 at 09:42:45, Russell King - ARM Linux wrote:
> On Tue, Nov 29, 2011 at 01:25:32AM +0100, Janusz Krzysztofik wrote:
> > However, the result of cpufreq_scale() differs from that of
> > (re)calibrate_delay() by ca. 6%, i.e., 70.40 vs. 74.54. Please advise if
> > this approximation is acceptable.
> 
> You don't say which figure is what.

Hi,
Those were BogoMIPS, which you were talking about in your comment 
(http://www.spinics.net/lists/linux-omap/msg60811.html).
> 
> Note that calibrate_delay() is itself inaccurate - the loops_per_jiffy
> is the number of loops which can be executed between two timer ticks
> _minus_ the time to process the timer interrupt itself.  So, it's
> actually always a little less than the theoretical number of loops
> within that time period.

I see. Then, in case of a machine always booting at, let's say, 12 and then reprogrammed to 150 MHz, we actually scale up that less then the theoretical number, with a side effect of scaling up its error as well. Perhaps in this case, when the machine is going to run at that target rate until rebooted, we should rather decide to recalibrate to keep that error proportionally small compared to the target loops per jiffy value, like it worked in my initial proposal? I think that your argument about unnecessarily wasting 10s of milliseconds has marginal importance here because we will be redoing that calibration only once, at boot time, and never later until next reboot.

Thanks,
Janusz
--
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/