Messages in this thread | | | Date | Thu, 14 Jul 2016 15:44:42 +0800 | From | xinhui <> | Subject | Re: [PATCH v3] locking/qrwlock: Let qrwlock has same layout regardless of the endian |
| |
On 2016年07月14日 03:54, Peter Zijlstra wrote: > On Mon, Jun 20, 2016 at 02:20:52PM +0800, Pan Xinhui wrote: >> This patch aims to get rid of endianness in queued_write_unlock(). We >> want to set __qrwlock->wmode to NULL, however the address is not >> &lock->cnts in big endian machine. That causes queued_write_unlock() >> write NULL to the wrong field of __qrwlock. >> >> Actually qrwlock can have same layout, IOW we can remove the #if >> __little_endian in struct __qrwlock. With such modification, we only >> need define some _QW* and _QR* with corresponding values in different >> endian systems. >> >> Suggested-by: Will Deacon <will.deacon@arm.com> >> Signed-off-by: Pan Xinhui <xinhui.pan@linux.vnet.ibm.com> >> Acked-by: Waiman Long <Waiman.Long@hpe.com> >> --- > > Urgh, I hate this stuff :/ > > OK, so I poked at this a bit and I ended up with the below; but now > qrwlock and qspinlock are inconsistent; although I suspect qspinlock is > similarly busted wrt endian muck. > > Not sure what to do.. > Lets talk about the qspinlock.
for x86, We has already assumed that ->locked sit at the low 8 bits, as is smp_store_release((u8 *)lock, 0);
Then we can do a favor, export ->locked but other fields as reserved. say
struct __qspinlock_unlcok_interface {/* what name is better?*/ #ifdef __LITTLE_ENDIAN u8 locked; u8 reserved[3]; /* do not touch it, internally use only */ #else u8 reserved[3]; u8 locked; #endif };
I think it is acceptable. and we can do similar things with qrwlock, too.
any thoughts?
> /* > - * Writer states & reader shift and bias > + * Writer states & reader shift and bias. > + * > + * | +0 | +1 | +2 | +3 | > + * ----+----+----+----+----+ > + * LE | 12 | 34 | 56 | 78 | 0x12345678 > + * ----+----+----+----+----+ > + * BE | 78 | 56 | 34 | 12 | 0x12345678 > + * ----+----+----+----+----+ > + * | wr | rd | > + * +----+----+----+----+ > + * > */
very clearly. :)
thanks xinhui
| |