> Date: Tue, 3 Apr 2018 12:36:18 +0200 > From: Martin Pieuchot <m...@openbsd.org> > > 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 :)
Option 1. doesn't rule this out. Having most (but not all) architectures using the MI implementation is still a win. The hppa mutex code is already written in C so it would be fairly easy do adjust it to provide the equivalent diagnostics. I can give that a go if you want me to.
