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

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

Message-Id: <1284112468-18498-1-git-send-email-ext-phil.2.carmody@nokia.com>
Date:	Fri, 10 Sep 2010 12:54:25 +0300
From:	Phil Carmody <ext-phil.2.carmody@...ia.com>
To:	mingo@...e.hu, gregkh@...e.de
Cc:	linux-kernel@...r.kernel.org, travis@....com, akataria@...are.com
Subject: [RFC 0/3] Improve fallback LPJ calculation

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/