[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v9 05/19] qspinlock: Optimize for smaller NR_CPUS
On Thu, Apr 17, 2014 at 05:46:27PM -0400, Waiman Long wrote: > On 04/17/2014 11:56 AM, Peter Zijlstra wrote: > >On Thu, Apr 17, 2014 at 11:03:57AM -0400, Waiman Long wrote: > >>+struct __qspinlock { > >>+ union { > >>+ atomic_t val; char bytes[4]; > >>+ struct { > >>+#ifdef __LITTLE_ENDIAN > >>+ u16 locked_pending; > >>+ u16 tail; > >>+#else > >>+ u16 tail; > >>+ u16 locked_pending; > >>+#endif > >>+ }; struct { #ifdef __LITTLE_ENDIAN u8 locked; #else u8 res[3]; u8 locked; #endif }; > >>+ }; > >>+}; > >>+ > >>+/** > >>+ * clear_pending_set_locked - take ownership and clear the pending bit. > >>+ * @lock: Pointer to queue spinlock structure > >>+ * @val : Current value of the queue spinlock 32-bit word > >>+ * > >>+ * *,1,0 -> *,0,1 > >>+ */ > >>+static __always_inline void > >>+clear_pending_set_locked(struct qspinlock *lock, u32 val) > >>+{ > >>+ struct __qspinlock *l = (void *)lock; > >>+ > >>+ ACCESS_ONCE(l->locked_pending) = 1; > >You lost the __constant_le16_to_cpu(_Q_LOCKED_VAL) there. The > >unconditional 1 is wrong. You also have to flip the bytes in > >locked_pending. > > I don't think that is wrong. The lock byte is in the least significant 8 > bits and the pending byte is the next higher significant 8 bits irrespective > of the endian-ness. So a value of 1 in a 16-bit context means the lock byte > is set, but the pending byte is cleared. The name "locked_pending" doesn't > mean that locked variable is in a lower address than pending. val is LE bytes[0,1,2,3] BE [3,2,1,0] locked_pending is LE bytes[0,1] BE [1,0] locked LE bytes[0] BE [0] That does mean that the LSB of BE locked_pending is bytes[1]. So if you do BE: locked_pending = 1, you set bytes[1], not bytes[0]. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |