On Wed, Dec 15, 2010 at 08:35:35AM -0500, Matthew Mondor wrote: > On Tue, 14 Dec 2010 20:49:14 -0800 > Matt Thomas <m...@3am-software.com> 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: da...@l8s.co.uk