Clock driven lbolt migration
Problem
Perhaps one of clock()'s most well known responsibilities is to bump the system wide tick counter, "lbolt", and it's 64 bit counterpart "lbolt64". lbolt is referenced extensively throughout the kernel serving as of the the kernel's primary (albeit low resolution) time base for consumers dealing in "ticks". Usually, lbolt increases at the rate of 100 times per second (but may tick faster, in some cases).
One benefit of this architecture, is that lbolt respresents a very low latency (to read) time source (on the order of a memory reference), but the obvious drawback, is that on an otherwise idle system, the system must wake up to service the clock interrupt to bump lbolt, which is inefficient from a power efficiency perspective.
Approach
Rather than having the OS maintain lbolt explicitly, we can instead leverage a running counter facility provided by the hardware. On SPARC, this can be "stick" (system tick) driven, where on x86 a number of choices exist (TSC, HPET, 8254, ...). This would mean lbolt (the variable) would become a light-weight function who's implementation involves reading reading the counter.
The challenges of this approach are (at least) two fold... First, there is a risk that existing consumers of lbolt rely on the low latency read performance, that might not be achievable in a hardware counter backed function call implementation. Extensive performance characterization will be needed, along with study of the (many) existing lbolt consumers.
Second, there is a risk that non-DDI compliant drivers exist that reference lbolt explicitly, rather than through ddi_get_lbolt(), and other suitable interfaces. This approach would break those drivers, as they would attempt to reference an external "lbolt" symbol in the kernel that is no longer present. The failure mode in this case would be that the driver would fail to load.
The up-shot of this approach is obviously that lbolt will cease to be clock() driven. Aside from the performance issues, this change should be fairly easy to implement, as lbolt would continue to provide a 100 Hz time source...although making ticks be of arbitrary resolution at this point would be trivial.
Project gate and webrev of current changes
The Mercurial source code repository is hosted at
ssh://anon@hg.opensolaris.org/hg/tickless/tickless-gate
This repository is synced against snv_121.
6860030 tickless clock requires a clock() decoupled lbolt / lbolt64
Our current webrev can be found at
[[http://cr.opensolaris.org/~rafaelv/webrev-10272/>>http://cr.opensolaris.org/~rafaelv/webrev-10272/]]
An updated version of the condvar(9F) man page can be found here.