tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Heads up: moving some uvmexp stat to being per-cpu
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
Home |
Main Index |
Thread Index |
Old Index