[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F7F5FB1C0@ORSMSX115.amr.corp.intel.com>
Date: Mon, 20 Apr 2020 20:45:33 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: "Williams, Dan J" <dan.j.williams@...el.com>,
Andy Lutomirski <luto@...capital.net>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, X86 ML <x86@...nel.org>,
stable <stable@...r.kernel.org>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
"Peter Zijlstra" <peterz@...radead.org>,
"Tsaur, Erwin" <erwin.tsaur@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-nvdimm <linux-nvdimm@...ts.01.org>
Subject: RE: [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast
> By "asynchronous" I don't mean "hours later".
>
> Make it be "interrupts are enabled, before serializing instruction".
>
> Yes, we want bounded error handling latency. But that doesn't mean "synchronous"
Another X86 vendor seems to be adding something like that. See MCOMMIT
in https://www.amd.com/system/files/TechDocs/24594.pdf
But I wonder how an OS will know whether it is running some smart
MCOMMIT-aware application that can figure out what to do with bad
data, or a legacy application that should probably be stopped before
it hurts somebody.
I also wonder how expensive MCOMMIT is (since it is essentially
polling for "did any errors happen").
-Tony
Powered by blists - more mailing lists