[RFC 0/3] Improve fallback LPJ calculation

[Phil Carmody]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/