better integration of osol cyclic with clocksource

I would like to commit the following patch soon, so I would like to ask you for
reviews and testing.

Idea of the patch is to improve integration with relatively recently introduced
clocksource framework.  Practical benefits are only achieved when one-shot
timers are used to drive a system.  In this case there will not be unnecessary
timer interrupts and, which is not the least, cyclic events should happen more
close to their scheduled times.  Currently cyclic subsystem is used only by
DTrace, so that means that DTrace profile provider becomes much more accurate.
E.g. if currently you specify profile:::profile-4001 probe and your hz is 1000,
then actually most of the time this probe is invoked 4 times in succession at
every hz tick.  With the proposed change it should be generally called every 250µs.

The patch:
http://people.freebsd.org/~avg/cyclic.diff

BIG NOTE: the patch needs osol gethrtime() to be implemented with the same
(high) prevision as the clocksource code, which is not the case now.  Without
that the cyclic code will work very unstably.  So one of the following actions
should be taken additionally:

A) The following patch changes gethrtime() to sufficiently accurate
implementation.  Since gethrtime() is also used in ZFS code, there is a concern
that the patch may negatively impact ZFS performance.  This hasn't been
demonstrated/proven, but I am also unable to conclusively prove that this will
not be the case.  The only argument that I have is that OpenSolaris uses a
precise implementation (based on TSC where possible), so the change shouldn't
make things worse than in OpenSolaris.

--- sys/cddl/compat/opensolaris/sys/time.h	(revision 221802)
+++ sys/cddl/compat/opensolaris/sys/time.h	(working copy)
_at__at_ -53,7 +53,7 _at__at_
 	struct timespec ts;
 	hrtime_t nsec;

-	getnanouptime(&ts);
+	nanouptime(&ts);
 	nsec = (hrtime_t)ts.tv_sec * NANOSEC + ts.tv_nsec;
 	return (nsec);
 }

B) Create a private copy of gethrtime() in sys/cddl/dev/cyclic/cyclic.c and
patch only that copy.
This is a safer approach suggested by pjd.  The only minor drawback is very
small code duplication.

-- 
Andriy Gapon