Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965405AbbLORxu (ORCPT ); Tue, 15 Dec 2015 12:53:50 -0500 Received: from mga02.intel.com ([134.134.136.20]:3013 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965235AbbLORxr (ORCPT ); Tue, 15 Dec 2015 12:53:47 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,433,1444719600"; d="scan'208";a="861317693" From: "Luck, Tony" To: "Williams, Dan J" , Borislav Petkov CC: Ingo Molnar , Andrew Morton , Andy Lutomirski , "linux-kernel@vger.kernel.org" , Linux MM , linux-nvdimm , X86 ML Subject: RE: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks Thread-Topic: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks Thread-Index: AQHRNzofOhVlt+R/OUCiyPbQy9P3LZ7M2FAA//96T6A= Date: Tue, 15 Dec 2015 17:53:31 +0000 Message-ID: <3908561D78D1C84285E8C5FCA982C28F39F8566E@ORSMSX114.amr.corp.intel.com> References: <23b2515da9d06b198044ad83ca0a15ba38c24e6e.1449861203.git.tony.luck@intel.com> <20151215131135.GE25973@pd.tnic> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsIiwiaWQiOiJhYjI4NDJlMS0yZTNhLTQ2NzYtYTFjYS1mYjY4NWJlNGI3NTMiLCJwcm9wcyI6W3sibiI6IkludGVsRGF0YUNsYXNzaWZpY2F0aW9uIiwidmFscyI6W3sidmFsdWUiOiJDVFBfSUMifV19XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTUuNC4xMC4xOSIsIlRydXN0ZWRMYWJlbEhhc2giOiJHQVFwWlZXSWpEU1l5Vk05NHZOOURvRTQxK3N6QmUwY0h1ZFN0NkhxN29rPSJ9 x-inteldataclassification: CTP_IC x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tBFHrtG4003623 Content-Length: 1126 Lines: 23 >> ... and the non-temporal version is the optimal one even though we're >> defaulting to copy_user_enhanced_fast_string for memcpy on modern Intel >> CPUs...? My current generation cpu has a bit of an issue with recovering from a machine check in a "rep mov" ... so I'm working with a version of memcpy that unrolls into individual mov instructions for now. > At least the pmem driver use case does not want caching of the > source-buffer since that is the raw "disk" media. I.e. in > pmem_do_bvec() we'd use this to implement memcpy_from_pmem(). > However, caching the destination-buffer may prove beneficial since > that data is likely to be consumed immediately by the thread that > submitted the i/o. I can drop the "nti" from the destination moves. Does "nti" work on the load from source address side to avoid cache allocation? On another topic raised by Boris ... is there some CONFIG_PMEM* that I should use as a dependency to enable all this? -Tony ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?