> On Dec 5, 2020, at 12:00 AM, Nicholas Piggin <npig...@gmail.com> wrote: > > > I disagree. Until now nobody following it noticed that the mm gets > un-lazied in other cases, because that was not too clear from the > code (only indirectly using non-standard terminology in the arch > support document).
> In other words, membarrier needs a special sync to deal with the case > when a kthread takes the mm. I don’t think this is actually true. Somehow the x86 oddities about CR3 writes leaked too much into the membarrier core code and comments. (I doubt this is x86 specific. The actual x86 specific part seems to be that we can return to user mode without syncing the instruction stream.) As far as I can tell, membarrier doesn’t care at all about laziness. Membarrier cares about rq->curr->mm. The fact that a cpu can switch its actual loaded mm without scheduling at all (on x86 at least) is entirely beside the point except insofar as it has an effect on whether a subsequent switch_mm() call serializes. If we notify membarrier about x86’s asynchronous CR3 writes, then membarrier needs to understand what to do with them, which results in an unmaintainable mess in membarrier *and* in the x86 code. I’m currently trying to document how membarrier actually works, and hopefully this will result in untangling membarrier from mmdrop() and such. A silly part of this is that x86 already has a high quality implementation of most of membarrier(): flush_tlb_mm(). If you flush an mm’s TLB, we carefully propagate the flush to all threads, with attention to memory ordering. We can’t use this directly as an arch-specific implementation of membarrier because it has the annoying side affect of flushing the TLB and because upcoming hardware might be able to flush without guaranteeing a core sync. (Upcoming means Zen 3, but the Zen 3 implementation is sadly not usable by Linux.)
