From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 72FEE211BA456 for ; Fri, 25 Jan 2019 10:20:58 -0800 (PST) From: "Verma, Vishal L" Subject: Re: [PATCH 5/5] dax: "Hotplug" persistent memory for use like normal RAM Date: Fri, 25 Jan 2019 18:20:56 +0000 Message-ID: References: <20190124231441.37A4A305@viggo.jf.intel.com> <20190124231448.E102D18E@viggo.jf.intel.com> <0852310e-41dc-dc96-2da5-11350f5adce6@oracle.com> <5A90DA2E42F8AE43BC4A093BF067884825733A5B@SHSMSX104.ccr.corp.intel.com> In-Reply-To: Content-Language: en-US Content-ID: <54E31B413D1FF149BE238966A26CD136@intel.com> MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: "Williams, Dan J" , "Du, Fan" Cc: "thomas.lendacky@amd.com" , "mhocko@suse.com" , "linux-nvdimm@lists.01.org" , "tiwai@suse.de" , "dave.hansen@linux.intel.com" , "Huang, Ying , linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "jglisse@redhat.com" , "Wu, Fengguang , baiyaowei@cmss.chinamobile.com" , "zwisler@kernel.org" , "bhelgaas@google.com" , "akpm@linux-foundation.org" , "bp@suse.de" List-ID: On Fri, 2019-01-25 at 09:18 -0800, Dan Williams wrote: > On Fri, Jan 25, 2019 at 12:20 AM Du, Fan wrote: > > Dan > > > > Thanks for the insights! > > > > Can I say, the UCE is delivered from h/w to OS in a single way in > > case of machine > > check, only PMEM/DAX stuff filter out UC address and managed in its > > own way by > > badblocks, if PMEM/DAX doesn't do so, then common RAS workflow will > > kick in, > > right? > > The common RAS workflow always kicks in, it's just the page state > presented by a DAX mapping needs distinct handling. Once it is > hot-plugged it no longer needs to be treated differently than "System > RAM". > > > And how about when ARS is involved but no machine check fired for > > the function > > of this patchset? > > The hotplug effectively disconnects this address range from the ARS > results. They will still be reported in the libnvdimm "region" level > badblocks instance, but there's no safe / coordinated way to go clear > those errors without additional kernel enabling. There is no "clear > error" semantic for "System RAM". > Perhaps as future enabling, the kernel can go perform "clear error" for offlined pages, and make them usable again. But I'm not sure how prepared mm is to re-accept pages previously offlined. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm