[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] performance counters



On 15/3/07 13:57, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

>> Well, they shouldn't be. Nearly all (apart from the array/histogram ones)
>> are per-cpu anyway. And even if they weren't, a few lost increments wouldn't
>> matter (assuming the read and write parts of the increment are each
>> themselves atomic -- otherwise you could get worse write-conflict problems
>> like word tearing).
> 
> Hmm, I wouldn't want to do away with the atomicity here altogether. That,
> however, would imply adding knowledge about the field name of the atomic_t
> to include/xen/perfc.h (and hence imply that all architectures use the same
> name here). Would you consider this acceptable?

Why is that? Every type of perfcounter (per-cpu, per-array, etc) has its own
declaration macro. You could change just the ones you want to be non-atomic
to 'unsigned int'. I'd be very much for getting rid of atomicity altogether,
at least on architectures where we know the resulting incorrectness is not
'too bad' (that includes x86). Some of the shared counters are on hot paths.
Alternatively we could make *all* counters per-cpu, even histogram counter
arrays.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.