[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4hAenpeqPsj7Rd0Un_SgDpm+CjqH3EK72ho-=zZFvG7wA@mail.gmail.com>
Date: Sat, 9 Jan 2016 14:15:09 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Tony Luck <tony.luck@...il.com>
Cc: Andy Lutomirski <luto@...capital.net>,
linux-nvdimm <linux-nvdimm@...1.01.org>,
Borislav Petkov <bp@...en8.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Robert <elliott@....com>, Ingo Molnar <mingo@...nel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>, X86 ML <x86@...nel.org>
Subject: Re: [PATCH v8 3/3] x86, mce: Add __mcsafe_copy()
On Sat, Jan 9, 2016 at 11:39 AM, Tony Luck <tony.luck@...il.com> wrote:
> On Sat, Jan 9, 2016 at 9:57 AM, Andy Lutomirski <luto@...capital.net> wrote:
>> On Sat, Jan 9, 2016 at 9:48 AM, Tony Luck <tony.luck@...il.com> wrote:
>>> ERMS?
>>
>> It's the fast string extension, aka Enhanced REP MOV STOS. On CPUs
>> with that feature (and not disabled via MSR), plain ol' rep movs is
>> the fastest way to copy bytes. I think this includes all Intel CPUs
>> from SNB onwards.
>
> Ah ... very fast at copying .. but currently not machine check recoverable.
Hmm, I assume for the pmem driver I'll want to check at runtime if the
cpu has machine check recovery and fall back to the faster copy if
it's not available?
Powered by blists - more mailing lists