Re: [Xen-devel] RFC: 32 bits as smallest atomic size.

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

>>>>> "KF" == Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> writes:

 KF> On 25 Mar 2005, at 23:49, Jimi Xenidis wrote:

 >> A few issues:
 >> 1) this assumes that the quantity is wholy contained in our atomic
 >> unit, by using packed there is no way to guarantee that.

 KF> We always naturally align fields, even in packed structs. The compiler 
 KF> doesn't do it for us, but we check it manually.

hmm, is it padding you are trying to avoid?
Perhaps not using packed and adding the gcc option '-Wpadded' which
will automagically catch the offenders for you might be more
appropriate?

Depending on manually checking can result in performance and
correctness issues that are difficult to track.

 >> 2) it would have to be a runtime decision on all PPC atomic
 >> operations that could fail with no real failure path available.

 KF> It may have to be a run-time decision unless we can come up with some 
 KF> clever trick. I don't understand what you mean about there being no 
 KF> failure path.

These are atomic operation, usually used in contexts where printing or
any other feedback is unavailable.


 KF> This may make sense since we do update those two fields as a pair. We 
 KF> have a big update to the grant table code about to be checked in. We 
 KF> shoudl hold off doing this kind of fix until after the update has been 
 KF> committed.

Agreed, its not like I'm even at the point of running this code :)
However, some attention to endianness would also be appreciated,
example common/grant_table.c:870 (and friends)
        /* Merge two 16-bit values into a 32-bit combined update. */
        /* NB. Endianness! */
        prev_scombo = scombo = ((u32)sdom << 16) | (u32)sflags;

 KF> We always naturally align fields. We may do *subword* accesses 
 KF> sometimes, but they are always naturally aligned and will never 
 KF> straddle a cacheline. I think that subword accesses should get fixed up 
 KF> in your ppc macros.

Could we not simply avoid *subword* accesses in common code as a rule?
It costs x86 nothing to do this and results in portable code.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel