Date: Thu, 26 Jan 2006 16:20:32 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@freebsd.org, current@freebsd.org Subject: Re: [TEST/REVIEW] CPU accounting patches Message-ID: <20060126162032.A16564@newtrinity.zeist.de> In-Reply-To: <23570.1138137045@critter.freebsd.dk>; from phk@phk.freebsd.dk on Tue, Jan 24, 2006 at 10:10:45PM %2B0100 References: <23570.1138137045@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 24, 2006 at 10:10:45PM +0100, Poul-Henning Kamp wrote: > > 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. > USIIe and greater CPUs support changing the CPU frequency which also affects the tick counter. Regarding CPUs currently supported by FreeBSD/sparc64 this translates to the 550MHz and 650MHz USIIi besides the USIIe CPUs. We currently don't support changing their frequency though but I think that would be easy to do. One other thing that might cause problems regarding your work is that the tick counters are not in sync across the CPUs of a MP system. We try to sync the tick counter of APs with the tick counter of the BSP when attaching the APs but that's already not perfect and they are not that constant over time. That's why we currently use the timecounter of a host-PCI or a host-SBus bridge respectively instead of the tick counters on USI/II MP systems. With USIII CPUs a MP system additionally can consist of different CPU models running at different clock speeds (and having different caches). Marius -- This mail was scanned by AntiVir Milter. This product is licensed for non-commercial use. See www.antivir.de for details.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060126162032.A16564>