Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
From: Linus Torvalds
Date: Fri Sep 08 2017 - 21:06:09 EST
On Fri, Sep 8, 2017 at 5:00 PM, Andy Lutomirski <luto@xxxxxxxxxx> wrote:
> I'm not convinced. The SDM says (Vol 3, 11.3, under WC):
> If the WC buffer is partially filled, the writes may be delayed until
> the next occurrence of a serializing event; such as, an SFENCE or
> MFENCE instruction, CPUID execution, a read or write to uncached
> memory, an interrupt occurrence, or a LOCK instruction execution.
> Thanks, Intel, for definiing "serializing event" differently here than
> anywhere else in the whole manual.
Yeah, it's really badly defined. Ok, maybe a locked instruction does
actually wait for it.. It should be invisible to anything, regardless.
> 1. The kernel wants to reclaim a page of normal memory, so it unmaps
> it and flushes. Another CPU has an entry for that page in its WC
> buffer. I don't think we care whether the flush causes the WC write
> to really hit RAM because it's unobservable -- we just need to make
> sure it is ordered, as seen by software, before the flush operation
> completes. From the quote above, I think we're okay here.
> 2. The kernel is unmapping some IO memory (e.g. a GPU command buffer).
> It wants a guarantee that, when flush_tlb_mm_range returns, all CPUs
> are really done writing to it. Here I'm less convinced. The SDM
> quote certainly suggests to me that we have a promise that the WC
> write has *started* before flush_tlb_mm_range returns, but I'm not
> sure I believe that it's guaranteed to have retired.
If others have writable TLB entries, what keeps them from just
continuing to write for a long time afterwards?
> I'd prefer to leave it as is except on the buggy AMD CPUs, though,
> since the current code is nice and fast.
So is there a patch to detect the 383 erratum and serialize for those?
I may have missed that part.