Date: Tue, 24 Jan 2006 22:10:45 +0100 From: Poul-Henning Kamp <phk@phk.freebsd.dk> To: arch@freebsd.org, current@freebsd.org Subject: [TEST/REVIEW] CPU accounting patches Message-ID: <23570.1138137045@critter.freebsd.dk>
next in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23570.1138137045>