Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3660949imu; Mon, 28 Jan 2019 08:36:23 -0800 (PST) X-Google-Smtp-Source: ALg8bN5g1xwMoNNKZ9mqbYn5If01mkAtUuj8FFpYX7duI5sy1Gans9q/ZX7r+tcIbJzIHXTVpEmr X-Received: by 2002:a63:fd53:: with SMTP id m19mr20667371pgj.340.1548693383533; Mon, 28 Jan 2019 08:36:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548693383; cv=none; d=google.com; s=arc-20160816; b=xsFGd3lzXZDJLYOjxbdYmd8zksobtO0QXJoS3t267vxrP4ESpVQGyXiZ6fkiKfxi/e G/F1agPp0H7so5GyrsMJ7EvUogX/CCDE2agpFqqrDsUmmrgYV0/fFGlKUZMNQxzYfsDt 34lFZDgXx/RP+/lN9AioA0ZHtZ2KRRBlUhbbE8p8NEauYF26EFaeVKmyp5hX2yV34rlS OiXisUuNA+m6UmCISoiBfP0hM01RmaJRHBurjLn4ryp+q37vqYuWwxhys56wLaLraUUE suZ/OXAbByb+1vIsBcZrTmKkyyh7Psj6r9c0cbUV9tdIy9K/7Tcs2rCB29L1Pv/JXZ6t gF7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=3RfSfUYfpAZphq/vcCmv0IEDUe5SxwKKRVSXT2VCPcU=; b=UMDTWGbV1sqTQJ/r13mRMgOyXvDZqsyh32VULF+2KOFUoOk+iyv8Wo8CswBsWUncbr ugoEr5EFuhge2c9vuOGceqZ+uYkQypSUP0DtIqHt7AWjz+rvBTbRgrL2Ch4qxvHlBAiK Eeq9wfRc1MhxK7+3WZUm1LTUFnQnIHo94SDYiVKE4na3h7MRtmMg1wglt7LG3XVcYDaO cWdCQn7xFbdVivo7vwWR3uJbWvspZAQ416/5QlNg5t0ZCyzw2JxRsmmxDSUBbzT/fJge QFWT+zuNi1oARcOwJHA1q7FLR19Az/vZTt9HepiD2xGWLvGvmoO6bkRsfmzvNnj3g9/z 924w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=2R9S32R3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t136si3434003pfc.262.2019.01.28.08.36.07; Mon, 28 Jan 2019 08:36:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=2R9S32R3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390392AbfA1QfI (ORCPT + 99 others); Mon, 28 Jan 2019 11:35:08 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:36419 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388520AbfA1QfH (ORCPT ); Mon, 28 Jan 2019 11:35:07 -0500 Received: by mail-oi1-f193.google.com with SMTP id x23so13539896oix.3 for ; Mon, 28 Jan 2019 08:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3RfSfUYfpAZphq/vcCmv0IEDUe5SxwKKRVSXT2VCPcU=; b=2R9S32R3QbZIbFSXmkascFMRRVMAOiMqJ3qvr07hqBS1ju4LNBiYd8iN0aJlFJ/JOd ElwAmIWmUZVOJZh97bQmAQNPXvf4VeX/+ilxGHTi0QIP+0rQncKNqMKRYlz+MSD4MPWe 7SOir2tSv8csXy26UxMYxsv2CVHTjd6wJ++zLlWA+0KqzFCGxEyu/6nu+5t98s1PMWuH 5zQibZ8M9eYLnxd+kpWMF/5/REPgfD5P0t+Rn9anI3+Izb4dePLt3HH+s6g9ZII/B1ph ENHZXTvgfY1CqvGoI4ipoCYITGRfAZREThglH4ckIwDdQ19VSdjSvyi+R7cgPuXSRaKf txJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3RfSfUYfpAZphq/vcCmv0IEDUe5SxwKKRVSXT2VCPcU=; b=hgtjGQMAe6Fcs664nFGUUrwbvUbEGCxJoi1623EKmRbnvJZ4FY5bHjghyiJfP6pnit rHQvS5fEsVS9Eza5otxfl89bafn4c7bgW7lAC43T2+mYl1PCQh64+O7XCoLPd4KCB1iI a5mvuER+/jInCtYXHT+l/Zb4lXwRveIi679hZeZVGQw3nQqL04KxnXQAGDXz4f2G07bz hItPpNHy4lEdcvYSyy1VGe+kS0nSZYsCx4WiGIGKmPu8tW31w+XAIztWLr3ZwiDz1WVO khZ9dvDo/NII6nvrtbmvo4FFqrbYTLIGI7Re9Ddul4WNlMyTy0GOSngVVPLkzKBFhMna mU/g== X-Gm-Message-State: AJcUukcfqQSxxTxOwjf6ZPH6v1RH/JNYHxJ8iG123rg9YRYWCjezaeuk oBVMguz9FO8ueut7KvYkYOp6eWrBUr2JSN5/mbfIOw== X-Received: by 2002:aca:b804:: with SMTP id i4mr6360983oif.280.1548693306097; Mon, 28 Jan 2019 08:35:06 -0800 (PST) MIME-Version: 1.0 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> <20190128092549.GF18811@dhcp22.suse.cz> In-Reply-To: <20190128092549.GF18811@dhcp22.suse.cz> From: Dan Williams Date: Mon, 28 Jan 2019 08:34:56 -0800 Message-ID: Subject: Re: [PATCH 5/5] dax: "Hotplug" persistent memory for use like normal RAM To: Michal Hocko Cc: Jane Chu , "Verma, Vishal L" , "Du, Fan" , "linux-kernel@vger.kernel.org" , "bp@suse.de" , "linux-mm@kvack.org" , "dave.hansen@linux.intel.com" , "tiwai@suse.de" , "akpm@linux-foundation.org" , "linux-nvdimm@lists.01.org" , "jglisse@redhat.com" , "zwisler@kernel.org" , "baiyaowei@cmss.chinamobile.com" , "thomas.lendacky@amd.com" , "Wu, Fengguang" , "Huang, Ying" , "bhelgaas@google.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 28, 2019 at 1:26 AM Michal Hocko wrote: > > On Fri 25-01-19 11:15:08, Dan Williams wrote: > [...] > > However, we should consider this along with the userspace enabling to > > control which device-dax instances are set aside for hotplug. It would > > make sense to have a "clear errors before hotplug" configuration > > option. > > I am not sure I understand. Do you mean to clear HWPoison when the > memory is hotadded (add_pages) or onlined (resp. move_pfn_range_to_zone)? Before the memory is hot-added via the kmem driver it shows up as an independent persistent memory namespace. A namespace can be configured as a block device and errors cleared by writing to the given "bad block". Once all media errors are cleared the namespace can be assigned as volatile memory to the core-kernel mm. The memory range starts as a namespace each boot and must be hotplugged via startup scripts, those scripts can be made to handle the bad block pruning.