Re: performance counters

["Jan Beulich" <jbeulich@novell.com>]

>>> Keir Fraser <keir@xensource.com> 15.03.07 15:01 >>>
>On 15/3/07 13:57, "Jan Beulich" <jbeulich@novell.com> 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,

Because that would require re-writing xen/common/perfc.c, which currently
assumes all 'struct perfcounter' members are of type atomic_t. Of course one
could also use ugly __typeof__ trickery to obtain the type of the field of atomic_t.

>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.

To me that would seem like the better alternative than dropping atomicity.

Jan