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

Re: [Xen-devel] performance counters

>>> Keir Fraser <keir@xxxxxxxxxxxxx> 15.03.07 15:01 >>>
>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,

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 

>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

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


Xen-devel mailing list



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