From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756331AbcAIWPN (ORCPT ); Sat, 9 Jan 2016 17:15:13 -0500 Received: from mail-yk0-f170.google.com ([209.85.160.170]:34837 "EHLO mail-yk0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756041AbcAIWPL (ORCPT ); Sat, 9 Jan 2016 17:15:11 -0500 MIME-Version: 1.0 In-Reply-To: References: <19f6403f2b04d3448ed2ac958e656645d8b6e70c.1452297867.git.tony.luck@intel.com> Date: Sat, 9 Jan 2016 14:15:09 -0800 Message-ID: Subject: Re: [PATCH v8 3/3] x86, mce: Add __mcsafe_copy() From: Dan Williams To: Tony Luck Cc: Andy Lutomirski , linux-nvdimm , Borislav Petkov , "linux-kernel@vger.kernel.org" , Andrew Morton , Robert , Ingo Molnar , "linux-mm@kvack.org" , X86 ML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 9, 2016 at 11:39 AM, Tony Luck wrote: > On Sat, Jan 9, 2016 at 9:57 AM, Andy Lutomirski wrote: >> On Sat, Jan 9, 2016 at 9:48 AM, Tony Luck 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? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) by kanga.kvack.org (Postfix) with ESMTP id 104CE828EE for ; Sat, 9 Jan 2016 17:15:11 -0500 (EST) Received: by mail-yk0-f170.google.com with SMTP id v14so303985975ykd.3 for ; Sat, 09 Jan 2016 14:15:11 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com. [2607:f8b0:4002:c07::22c]) by mx.google.com with ESMTPS id t206si66210909ywb.281.2016.01.09.14.15.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jan 2016 14:15:10 -0800 (PST) Received: by mail-yk0-x22c.google.com with SMTP id x67so397909214ykd.2 for ; Sat, 09 Jan 2016 14:15:10 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <19f6403f2b04d3448ed2ac958e656645d8b6e70c.1452297867.git.tony.luck@intel.com> Date: Sat, 9 Jan 2016 14:15:09 -0800 Message-ID: Subject: Re: [PATCH v8 3/3] x86, mce: Add __mcsafe_copy() From: Dan Williams Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Tony Luck Cc: Andy Lutomirski , linux-nvdimm , Borislav Petkov , "linux-kernel@vger.kernel.org" , Andrew Morton , Robert , Ingo Molnar , "linux-mm@kvack.org" , X86 ML On Sat, Jan 9, 2016 at 11:39 AM, Tony Luck wrote: > On Sat, Jan 9, 2016 at 9:57 AM, Andy Lutomirski wrote: >> On Sat, Jan 9, 2016 at 9:48 AM, Tony Luck 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? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org