[TEST/REVIEW] CPU accounting patches

Here is a new version of my cpu accounting change patch.

	http://phk.freebsd.dk/patch/cpu_acct_1.patch

This patch is supposedly harmless (or at least mostly harmless)
and I'd appreciate it getting a solid trashing.


This patchs changes cpu accounting from accumulating charges
in real-time units and instead accumulates in units of some
per-arch, possibly per-cpu counter.

When the accumulated charge is read by times(2) or getrusage(2) or
similar, the frequency of the counter is interrogated and the charge
normalized to microseconds.

With this patch, the counter is always the timecounter and the only
real difference is therefore a minor performance change (because we
save the normalizing multiplications for each context switch).

On my AMD Athlon 700 and my Sun Ultra 60 the performance difference
is barely 1% and of doubtful statistical quality.

On my Opteron machine I get a 2.7+/-.6% boost on unixbench's
context1 test.

Of course, the scheme used in this patch suffers a bit if the
hardware counter changes to other hardware of a different rate
or simply changes rate.  This has been discussed at length in
a previous thread already, and I'll simply refer to it, rather
than rehash here:

http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008637.html



The other half of this work is in this separate patch, and this is
not yet complete.  You are welcome to test it however, as long as
you are aware of the problems it may hold:

	http://phk.freebsd.dk/patch/cpu_acct_2.patch

It makes i386 and amd64 use the TSC and sparc64 use the "tick"
counter for CPU accounting.

On a sparc64 it gives 3.2+/-.3% speedup on unixbench/context1

On a Athlon700 with i8254 timecounter it gives a 95+/-.8% speedup

On a Opteron with ACPI-fast timecounter it gives a 36+/-.6% speedup.

The downside is, that unless your cpu clock is correctly probed
at boot and stays constant, your cpu accounting numbers will have
a bogus scaling factor.

I belive all the sparc64s we support have constant CPU rates,
so they should be safe.

For i386 and amd64 things are more tricky.  Laptops doing power
saving tricks will probably give bogus cpu accounting values,
but as such the patch should do no other harm than screw up
those values.

If you benchmark this patch, please understand that it is vitally
important that you benchmark relative to the real-time scale (ie:
wall-clock time), the "user" and "system" fields from time(1) are
not usable.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.