I've had a play at using the MI microtime() in kern/kern_microtime.c
on evbmips (on a 396MHz Au1500 eval board), and using the cycle
counter for measuring the speed between the splclock()/splx() calls in
arch/evbmips/evbmips/clock.c and kern/kern_microtime.c I see that the
evbmips microtime takes about 1.4us and the MI microtime takes about
4.8us.

The current evbmips microtime (sbmips and sgimips should be similar)
gets by with a single multiply (see arch/mips/include/cpu.h around line
72 for info), while the MI microtime ends up with three multiplies and a
call to __divdi3.  Changing the MI microtime to use 32-bit ints instead
of 64-bit ints gets back to a multiply and a divide (integer divides can
be _slow_ on a lot of MIPS cores), and back to 1.5us.

I think the only place we really need 64-bit arithmetic is in this
sequence in kern/kern_microtime.c:

	int64_t usec;

	usec = cpu_counter32() - ci->ci_cc_cc;
	if (usec < 0)
		usec += 0x100000000LL;
	t.tv_usec += (usec * ci->ci_cc_ms_delta) / ci->ci_cc_denom;

Two things I'd like to be able to do:

 1- Have a way of overriding the 64-bit integer currently used
    (MICROTIME_CALC_TYPE or something less ugly).  If this happened
    to be a uint32_t and cpu_counter32() returns a uint32_t then we
    also don't need the "if (usec < 0)" test either.

 2- Have a way of overriding the
	(usec * ci->ci_cc_ms_delta) / ci->ci_cc_denom
    expression.

So, is the idea of trying to make microtime() faster worth chasing up
any more?  If so, are the above ideas on the right track?

Simon.
--
Simon Burge                                   <simonb@wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/