Re: Heads up: moving some uvmexp stat to being per-cpu

[David Laight <david%l8s.co.uk@localhost>]

On Wed, Dec 15, 2010 at 08:35:35AM -0500, Matthew Mondor wrote:
> On Tue, 14 Dec 2010 20:49:14 -0800
> Matt Thomas <matt%3am-software.com@localhost> wrote:
> 
> > I have a fairly large but mostly simple patch which changes the stats 
> > collected in
> > uvmexp for faults, intrs, softs, syscalls, and traps from 32 bit to 64 bits 
> > and
> > puts them in cpu_data (in cpu_info).  This makes more accurate and a little 
> > cheaper
> > to update on 64bit systems.
> 
> I like the cleanliness of the changes;
> 
> A potential issue I see is how heavy this becomes on some 32-bit CPUs
> i.e. m68k, where I see for instance 1 instruction being replaced by 9
> instructions (including registers save/restore) to increment a
> counter.  I'm not sure if in practice this will really affect
> performance, or if it's worth benchmarking for those architectures,
> however.
> 
> If it turned out to be a problem, I could see two possible solutions:
> an option to disable some stat counters on slow systems (values could
> simply remain 0 in that case), or a new counter type say,
> cpustatcount_t and macros defined by the MD code to use 32-bit
> cpu-specific counters where necessary, getting compiled/exported to
> userland using 64-bit at statistics request time to avoid
> compat/userland complications...

I'd have thought it wasn't really a problem to have the values
wrap at 2^32.
Anything doing differences can easily tell when a value wraps (providing
it is sampling it often enough to get a sensible value at all).

        David

-- 
David Laight: david%l8s.co.uk@localhost