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] RFC: 32 bits as smallest atomic size.

To: "Hollis Blanchard" <hollisb@xxxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] RFC: 32 bits as smallest atomic size.
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Tue, 29 Mar 2005 23:00:57 +0100
Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 29 Mar 2005 22:01:08 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcU0qCNIrJOmzQhhR8qAiy01laby0wAAE+6g
Thread-topic: [Xen-devel] RFC: 32 bits as smallest atomic size.
> Right now there is a single problematic cmpxchg user, 
> grant_entry_t, and the impact of the fix is tiny (make the 
> 'flags' member 4 bytes). Is that too large an inconvenience?

That would make grant table entries 12 bytes rather than 8 bytes, which
is not ideal given that you can end up needing quite a lot of them,
particularly when the cacheline packing is considered. 

Perhaps the best thing to do would be to change that particular instance
of cmpxchg into cmpxchg_16, where we handle the subword case on
architectures which can't do it directly by rounding down the address,
doing a read, insert, and cmpxchg. 

This seems a better fix, at least to me.


Xen-devel mailing list