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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home
xen.org, 