From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) by kanga.kvack.org (Postfix) with ESMTP id 4AFBF6B0253 for ; Tue, 15 Dec 2015 13:35:50 -0500 (EST) Received: by mail-qg0-f50.google.com with SMTP id v16so14787701qge.0 for ; Tue, 15 Dec 2015 10:35:50 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com. [2607:f8b0:400d:c09::234]) by mx.google.com with ESMTPS id c13si2242298qkb.79.2015.12.15.10.35.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Dec 2015 10:35:49 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id u65so8236890qkh.2 for ; Tue, 15 Dec 2015 10:35:49 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <23b2515da9d06b198044ad83ca0a15ba38c24e6e.1449861203.git.tony.luck@intel.com> <20151215131135.GE25973@pd.tnic> <3908561D78D1C84285E8C5FCA982C28F39F8566E@ORSMSX114.amr.corp.intel.com> Date: Tue, 15 Dec 2015 10:35:49 -0800 Message-ID: Subject: Re: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks From: Dan Williams Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: "Luck, Tony" Cc: Borislav Petkov , Ingo Molnar , Andrew Morton , Andy Lutomirski , "linux-kernel@vger.kernel.org" , Linux MM , linux-nvdimm , X86 ML On Tue, Dec 15, 2015 at 10:27 AM, Dan Williams wrote: > On Tue, Dec 15, 2015 at 9:53 AM, Luck, Tony wrote: >>>> ... 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? > > My mistake, I don't think we have an uncached load capability, only store. Correction we have MOVNTDQA, but that requires saving the fpu state and marking the memory as WC, i.e. probably not worth it. -- 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