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?
IBM Linux Technology Center
Xen-devel mailing list