On 7/11/2018 10:00 AM, Peter Zijlstra wrote: > On Wed, Jul 11, 2018 at 04:57:51PM +0100, Will Deacon wrote: > >> It might be simple to model, but I worry this weakens our locking >> implementations to a point where they will not be understood by the average >> kernel developer. As I've said before, I would prefer "full" RCsc locking, > > Another vote for RCsc locks. The (in)famous hold-out is of course > PowerPC, but it now looks like RISC-V is following where they I really > rather wish they didn't.
That's not entirely fair. We came in wanting to do the "natural" or "expected" thing: use RCsc atomics where we have them available in the ISA, and use "fence r,rw" and "fence rw,w" where we don't. I would argue that the idea of having data races on variables that are also protected by locks is equally if not more counterintuitive and unexpected than the "natural" mapping we had originally proposed to use. All the discussion here[1] for example is about having ordering and doing an smp_cond_load_acquire() on a variable which is sometimes protected by a CPU's rq->lock and sometimes not? Isn't that one of the key use cases for this whole discussion? FWIW, this code also mixes locking, smp_rmb(), and smp_cond_load_acquire() all in very close proximity with each other... I suppose there's no mixing and matching on the same variable, but we are here trying to reason about how all those pieces interact, no? [1] https://lkml.org/lkml/2015/10/6/805 Dan
