On 03/04/18(Tue) 12:06, Mark Kettenis wrote: > > Date: Tue, 3 Apr 2018 11:16:45 +0200 > > From: Martin Pieuchot <m...@openbsd.org> > > > > Here's a diff to switch hppa to the MI mutex implementation. I'm > > looking for testers, as I don't own such hardware. > > > > Note that our MI mutex implementation relies on atomic_cas_ptr(9). On > > hppa all the calls to this function are serialized on a single lock. I > > don't believe it will introduce contention at this point since the > > KERNEL_LOCK() is still the problem. However if it becomes a bottleneck > > we could use multiple locks in a small hash table. > > I don't have such hardware either, but I'm not in favour of doing > this. PA-RISC is "challenged" but at least the locking primitive it > supplies is suitable for implementing spin locks. Emulating CAS with > spin locks to implement a spin lock feels so wrong. There are also > some concerns about guarantees of forward progress in such an > implementation.
Well I would prefer if we could solve these concerns because we are already using atomic operations. So what are the options? 1. Keep hppa mutex MD and start diverging with the MI mutex 2. Add another MI layer of abstraction on top of the atomic*(9) API because of hppa 3. Emulate the atomic*(9) API as well as we can on hppa I picked 3 because I don't want to add more complexity for an arch which is not widely used. Who care if it feels wrong to emulate a CAS with a hw spinlock? I believed that what we need is locking primitives that we can debug and analyse. If hppa can benefit from that and help us find bugs, that's even better :) Do you see another alternative?
