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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ