From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by kanga.kvack.org (Postfix) with ESMTP id 14FE58E00BD for ; Fri, 25 Jan 2019 03:20:51 -0500 (EST) Received: by mail-pl1-f200.google.com with SMTP id y2so5869022plr.8 for ; Fri, 25 Jan 2019 00:20:51 -0800 (PST) Received: from mga07.intel.com (mga07.intel.com. [134.134.136.100]) by mx.google.com with ESMTPS id w185si4457311pfw.122.2019.01.25.00.20.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jan 2019 00:20:49 -0800 (PST) From: "Du, Fan" Subject: RE: [PATCH 5/5] dax: "Hotplug" persistent memory for use like normal RAM Date: Fri, 25 Jan 2019 08:20:45 +0000 Message-ID: <5A90DA2E42F8AE43BC4A093BF067884825733A5B@SHSMSX104.ccr.corp.intel.com> References: <20190124231441.37A4A305@viggo.jf.intel.com> <20190124231448.E102D18E@viggo.jf.intel.com> <0852310e-41dc-dc96-2da5-11350f5adce6@oracle.com> In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: "Williams, Dan J" , Jane Chu Cc: Tom Lendacky , Michal Hocko , linux-nvdimm , Takashi Iwai , Dave Hansen , "Huang, Ying" , Linux Kernel Mailing List , Linux MM , =?iso-8859-1?Q?J=E9r=3Fme_Glisse?= , Borislav Petkov , Yaowei Bai , Ross Zwisler , Bjorn Helgaas , Andrew Morton , "Wu, Fengguang" , "Du, Fan" Dan Thanks for the insights! Can I say, the UCE is delivered from h/w to OS in a single way in case of m= achine 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? And how about when ARS is involved but no machine check fired for the funct= ion of this patchset? >-----Original Message----- >From: Linux-nvdimm [mailto:linux-nvdimm-bounces@lists.01.org] On Behalf >Of Dan Williams >Sent: Friday, January 25, 2019 2:28 PM >To: Jane Chu >Cc: Tom Lendacky ; Michal Hocko >; linux-nvdimm ; Takashi >Iwai ; Dave Hansen ; Huang, >Ying ; Linux Kernel Mailing List >; Linux MM ; J=E9r=F4me >Glisse ; Borislav Petkov ; Yaowei Bai >; Ross Zwisler ; >Bjorn Helgaas ; Andrew Morton >; Wu, Fengguang >Subject: Re: [PATCH 5/5] dax: "Hotplug" persistent memory for use like >normal RAM > >On Thu, Jan 24, 2019 at 10:13 PM Jane Chu wrote: >> >> Hi, Dave, >> >> While chatting with my colleague Erwin about the patchset, it occurred >> that we're not clear about the error handling part. Specifically, >> >> 1. If an uncorrectable error is detected during a 'load' in the hot >> plugged pmem region, how will the error be handled? will it be >> handled like PMEM or DRAM? > >DRAM. > >> 2. If a poison is set, and is persistent, which entity should clear >> the poison, and badblock(if applicable)? If it's user's responsibility, >> does ndctl support the clearing in this mode? > >With persistent memory advertised via a static logical-to-physical >storage/dax device mapping, once an error develops it destroys a >physical *and* logical part of a device address space. That loss of >logical address space makes error clearing a necessity. However, with >the DRAM / "System RAM" error handling model, the OS can just offline >the page and map a different one to repair the logical address space. >So, no, ndctl will not have explicit enabling to clear volatile >errors, the OS will just dynamically offline problematic pages. >_______________________________________________ >Linux-nvdimm mailing list >Linux-nvdimm@lists.01.org >https://lists.01.org/mailman/listinfo/linux-nvdimm