This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] performance counters

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] performance counters
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Thu, 15 Mar 2007 14:37:33 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 15 Mar 2007 07:35:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C21F0244.B8C9%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <45F95EBF.76E4.0078.0@xxxxxxxxxx> <C21F0244.B8C9%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> 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