On Fri, Feb 07, 2014 at 12:49:49PM +0100, Torsten Duwe wrote: > On Fri, Feb 07, 2014 at 11:45:30AM +0100, Peter Zijlstra wrote: > > > > That might need to be lhz too, I'm confused on all the load variants. > > ;-) > > > > unlock: > > > lhz %0, 0, &tail > > > addic %0, %0, 1 > > No carry with this one, I'd say.
Right you are, add immediate it is. > Besides, unlock increments the head. No, unlock increments the tail, lock increments the head and waits until the tail matches the pre-inc value. That said, why do the atomic_inc() primitives do an carry add? (that's where I borrowed it from). > > > lwsync > > > sth %0, 0, &tail > > > > > Given the beauty and simplicity of this, may I ask Ingo: > you signed off 314cdbefd1fd0a7acf3780e9628465b77ea6a836; > can you explain why head and tail must live on the same cache > line? Or is it just a space saver? I just ported it to ppc, > I didn't think about alternatives. spinlock_t should, ideally, be 32bits. > What about > > atomic_t tail; > volatile int head; ? > > Admittedly, that's usually 8 bytes instead of 4... That still won't straddle a cacheline unless you do weird alignement things which will bloat all the various data structures more still. Anyway, you can do a version with lwarx/stwcx if you're looking get rid of lharx. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
