[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [rfc] [patch] grant_entry.flags accessors




On 27 Jun 2006, at 18:45, Jimi Xenidis wrote:

Hmm, the interesting part is that as far as bit-ops go in Linux x86 converged to longs rather then ppc converging to some the arbitrary bit method:
see:
include/asm-i386/bitops.h clear_bit 71 static inline void clear_bit(int nr, volatile unsigned long * addr)

I've been told this was to solve a performance issue, but I am no expert.

Well there would be a performance impact for other architectures, no doubt. x86/64 never moved to longs for bitops.

, but anyway: How about add a ARCH_SUPPORTS_UNALIGNED_CMPXCHG and move special gnttab_cmpxchg() definition to gnttab.c, compilation dependent on that?

cmpxchg will take 1,2,4 byte, and pc will take to, however we need to abstract these anyway because the values are castes to a u32 and or'd in an little endian way.

Or rename the gnttab_cmpxchg to synch_cmpxchg_unaligned so at least the name is a bit more generic. It could then be used in other contexts.

The _main_ issue is not really alignof(p), beacuse the Xen code is careful about that, but sizeof(*p)which we need to calculate the bit position. Thats where this interface can get a little loosy for me.

Then pick a different name. :-) *_subword()? I won't put a gnttab_foo() in synch_bitops.h.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.