Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp802253ybv; Fri, 7 Feb 2020 08:46:28 -0800 (PST) X-Google-Smtp-Source: APXvYqwN4//MI1tFEBGjDtQOxvgD4irUxm+O25KHTpGzVq/feoGLMWp8iCq5+LcT4xbfG7C6RHNp X-Received: by 2002:aca:4f8e:: with SMTP id d136mr2611556oib.61.1581093988638; Fri, 07 Feb 2020 08:46:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581093988; cv=none; d=google.com; s=arc-20160816; b=PAaLhYZPzm9yS3u0Ea50QCGW8hh7hGdU0jB5pITzcBRDP8lA5uBJOe+MH1NV/7U9wX zgMtf0+h4Uo29ECDwaJRkHW1gnp3e0bsjawZ5gvqSmCtNDdXnPGzqZ4Ppo6VEif1FQf3 jCjBfggKti2FBBPMOnYuiNGkGH2+Fl4h2uwgRJzlcVWU6dugQzD4vrhO6Ko54hZdyeTX UfWsT13+OHzr9iJxJcxZO5Vs6PtSSuxtV/HUtOrUm5zGCbCXAVTj/ywqxyhMYLnL7xQJ OyKfCjhxYW5W4lJMJsN00kjAfHu3MXSW2BRPPrSGR9h+sPw5AiRm1jlU3AusTifr6kD8 dJSg== 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=rIOuP/1Ysr2MuixCGeN5opf7BC+IIc7SOpxNoaJ25FU=; b=Kd+9PJBaRNYQOi7igjwmqj1HjwfFT0MN5GUZekBf9WsRhP0V6B9uogImbTp/JfcGRW yhRZmSAEaMcBFg0ubV2pIK6B6qhGliq3izZ9VPHnFxnQxd8+WoyvIMTMvtwUr74DPCB9 CAcXp2IUR5GrVY0cAowo/+P22kwzzS8t8mbzS2Wcc90ra3yNL9Q0pJ+o9txaUE9eUQwG /P5RmYMOnPwIKcex9nGOZzo7+aZDSM/nGmkKAinuH9ADPBTucnTsFhlBVUssbxl+X43D MaDfLufHMwikWeXeLrKRMRUXop2oky1KK9d3Utn9IwYADGFrs5puG44uf5WPCc7qQsvF RcvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=OlrtI16M; 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 q17si1956431otk.321.2020.02.07.08.46.11; Fri, 07 Feb 2020 08:46:28 -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=OlrtI16M; 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 S1727011AbgBGQpJ (ORCPT + 99 others); Fri, 7 Feb 2020 11:45:09 -0500 Received: from mail-oi1-f196.google.com ([209.85.167.196]:46083 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726897AbgBGQpJ (ORCPT ); Fri, 7 Feb 2020 11:45:09 -0500 Received: by mail-oi1-f196.google.com with SMTP id a22so2539638oid.13 for ; Fri, 07 Feb 2020 08:45:08 -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=rIOuP/1Ysr2MuixCGeN5opf7BC+IIc7SOpxNoaJ25FU=; b=OlrtI16MC0ud/tLym/B8Vg0C2/zcuEAfJ6/hNyd5RIQM4tAjVNYb3zY1VSpb5/ZCUa kRPPVciTb4JZ43LXuOse1RpL1Y8rLZulnxdNpVMdqEDc3OxG9H0RWx/1IoitGDloRa+s 0AeQuckcBFd5uC/gKLrLoWoXEbxO39XqIBPFYr4/M3k9Z2koBjgZV4PXWow4ZHY90wr+ 6INZJuHQpTK/jX4fS+Pua80XHY6aT7WA8UM/1YIMvts4JTvmA1TT5afQhWQj3ThnE7HG xD1nBbgcNpyQ3wpNd6KfDJA8g5wdyglKkvx+x1Lsg3Rxp6+gTJtexD5NRTuIff+V/Q3r YSGg== 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=rIOuP/1Ysr2MuixCGeN5opf7BC+IIc7SOpxNoaJ25FU=; b=b7RMWTKCULn7H16cg7FErApFROv/KpTkGfONvLfyJp8sFOdbjyGi+5cUa7CtSM4052 EE/hte45C7ySmljPEGjnd5FiBxBjLsdvU8WAAgOQUcEo71Rw2UvxqU7Ps9vbLLzvpxoj DMVimKpcUXp5BemlDO9Hvspj82YRdJuycxWRoO5C6wFQhD9lUMRLAdEi9UQ10vC/jG/f h+rY35Xzp/MJR/SFJfAxuE+JcA1bVzxhfZqKYmkc9E+t/Ozms8fe8vYnRt0j7WjvBD9e TNQeaK5KSqBi9rw10JIGOvQFlqUawgGzLcwfSUX/TLHLvNWfy/pngrCjwmo6oF5A0SLn 9lvQ== X-Gm-Message-State: APjAAAWxNbr5KyADmBeQg1qLlwLHsJlUCRGqsrmuCm4GHeifRfNEF+Ik 2mM8CG5XTztiKVdJk1dsMD89TcYjxdiodwfkAbWZVQ== X-Received: by 2002:aca:aa0e:: with SMTP id t14mr2694999oie.149.1581093908242; Fri, 07 Feb 2020 08:45:08 -0800 (PST) MIME-Version: 1.0 References: <20200206231629.14151-1-richardw.yang@linux.intel.com> <20200206231629.14151-3-richardw.yang@linux.intel.com> <20200207031011.GR8965@MiWiFi-R3L-srv> <20200207121453.pgi4axyvx6peqgeo@master> In-Reply-To: <20200207121453.pgi4axyvx6peqgeo@master> From: Dan Williams Date: Fri, 7 Feb 2020 08:44:57 -0800 Message-ID: Subject: Re: [PATCH 2/3] mm/sparsemem: get physical address to page struct instead of virtual address to pfn To: Wei Yang Cc: Baoquan He , Wei Yang , Andrew Morton , Oscar Salvador , Linux MM , Linux Kernel Mailing List , David Hildenbrand 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 Fri, Feb 7, 2020 at 4:15 AM Wei Yang wrote: > > On Thu, Feb 06, 2020 at 07:21:49PM -0800, Dan Williams wrote: > >On Thu, Feb 6, 2020 at 7:10 PM Baoquan He wrote: > >> > >> Hi Dan, > >> > >> On 02/06/20 at 06:19pm, Dan Williams wrote: > >> > On Thu, Feb 6, 2020 at 3:17 PM Wei Yang wrote: > >> > > diff --git a/mm/sparse.c b/mm/sparse.c > >> > > index b5da121bdd6e..56816f653588 100644 > >> > > --- a/mm/sparse.c > >> > > +++ b/mm/sparse.c > >> > > @@ -888,7 +888,7 @@ int __meminit sparse_add_section(int nid, unsigned long start_pfn, > >> > > /* Align memmap to section boundary in the subsection case */ > >> > > if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP) && > >> > > section_nr_to_pfn(section_nr) != start_pfn) > >> > > - memmap = pfn_to_kaddr(section_nr_to_pfn(section_nr)); > >> > > + memmap = pfn_to_page(section_nr_to_pfn(section_nr)); > >> > > >> > Yes, this looks obviously correct. This might be tripping up > >> > makedumpfile. Do you see any practical effects of this bug? The kernel > >> > mostly avoids ->section_mem_map in the vmemmap case and in the > >> > !vmemmap case section_nr_to_pfn(section_nr) should always equal > >> > start_pfn. > >> > >> The practical effects is that the memmap for the first unaligned section will be lost > >> when destroy namespace to hot remove it. Because we encode the ->section_mem_map > >> into mem_section, and get memmap from the related mem_section to free it in > >> section_deactivate(). In fact in vmemmap, we don't need to encode the ->section_mem_map > >> with memmap. > > > >Right, but can you actually trigger that in the SPARSEMEM_VMEMMAP=n case? > > > >> By the way, sub-section support is only valid in vmemmap case, right? > > > >Yes. > > Just one question from curiosity. Why we don't want sub-section for !vmemmap > case? Because it will wast memory for memmap? The effort and maintenance burden outweighs the benefit.