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: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] RFC: 32 bits as smallest atomic size.
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Tue, 29 Mar 2005 16:32:31 -0600
Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 29 Mar 2005 22:34:53 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D1E3910@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Organization: IBM Linux Technology Center
References: <A95E2296287EAD4EB592B5DEEFCE0E9D1E3910@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2005-03-29 at 23:00 +0100, Ian Pratt wrote:
> > 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. 

If you look closely, that code is a hack that Keir mentioned would be
replaced soon. Two 16-bit quantities are being concatenated (in an
endian-unsafe manner), then passed as a 32-bit quantity to cmpxchg,
using the address of the first 16-bit value.

I was looking for a more general policy though. There are a number of
atomic operations (including xchg, cmpxchg, bitops' *_bit, and atomic_*)
that will require extra code (to write and run) on many architectures,
if the types used are not native word size. Why shouldn't Xen follow
Linux's example here?

Hollis Blanchard
IBM Linux Technology Center

Xen-devel mailing list