linux-kernel - Re: [RFC 0/3] Improve fallback LPJ calculation

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] [day] [month] [year] [list]

Message-ID: <20100922092228.GJ2926@esdhcp04044.research.nokia.com>
Date:	Wed, 22 Sep 2010 12:22:28 +0300
From:	Phil Carmody <ext-phil.2.carmody@...ia.com>
To:	"mingo@...e.hu" <mingo@...e.hu>, "gregkh@...e.de" <gregkh@...e.de>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"travis@....com" <travis@....com>,
	"akataria@...are.com" <akataria@...are.com>, tony@...mide.com,
	linux-omap@...r.kernel.org
Subject: Re: [RFC 0/3] Improve fallback LPJ calculation


Adding Tony and Linux-OMAP cc:, as this patchset was written specifically
with the OMAP in mind (thread rooted at http://lkml.org/lkml/2010/9/10/104 ).
Any comments would be appreciated.

Phil

On 10/09/10 11:54 +0200, Carmody Phil.2 (EXT-Ixonos/Helsinki) wrote:
> 
> The motivation for patch 2/3 is that currently our OMAP calibrates
> itself using the trial-and-error binary chop fallback that some other
> architectures no longer need to perform. This is a lengthy process, 
> taking 0.2s in an environment where boot time is of great interest.
> 
> The patch has two optimisations. Firstly, it replaces the initial 
> repeated-doubling to find the relevant power of 2 with a tight loop 
> that just does as much as it can in a jiffy. Secondly, it doesn't 
> binary chop over an entire power of 2 range, it choses a much smaller
> range based on how much it squeezed in, and failed to squeeze in, 
> during the first stage. Both are significant optimisations, and 
> bring our calibration down from 23 jiffies to 6, and, in the process,
> arrive at a more accurate lpj value.
> 
> The 'bands' and 'sub-logarithmic' growth may look over-engineered,
> but they cost a small level of in inaccuracy of the initial guess
> (for all architectures) in order to avoid the very large inaccuracies 
> that appeared during testing (on x86_64 architectures, and presumably 
> others with less metronomic operation). Note that due to the existence
> of the TSC and other timers, the x86_64 doesn't use this fallback 
> routine, but I wanted to code defensively, able to cope with all kinds
> of processor behaviours.
> 
> 1/3 is simply cosmetic to prepare for 2/3. 
> 3/3 is simply to assist testing and not intended for integration.
> 
> I would appreciate it if people with exotic or unusual architectures
> could help test this.
> 
> Cheers,
> Phil
> --
> 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/
> 
--
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/