From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 339B7C43613 for ; Thu, 20 Jun 2019 17:00:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0FBA620656 for ; Thu, 20 Jun 2019 17:00:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726649AbfFTRAm (ORCPT ); Thu, 20 Jun 2019 13:00:42 -0400 Received: from mx2.suse.de ([195.135.220.15]:59374 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726562AbfFTRAm (ORCPT ); Thu, 20 Jun 2019 13:00:42 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 89D3BAFC3; Thu, 20 Jun 2019 17:00:40 +0000 (UTC) Date: Thu, 20 Jun 2019 19:00:35 +0200 From: Oscar Salvador To: Dan Williams Cc: akpm@linux-foundation.org, David Hildenbrand , =?iso-8859-1?B?Suly9G1l?= Glisse , Mike Rapoport , Jane Chu , Pavel Tatashin , Jonathan Corbet , Qian Cai , Logan Gunthorpe , Toshi Kani , Jeff Moyer , Michal Hocko , Vlastimil Babka , stable@vger.kernel.org, Wei Yang , linux-mm@kvack.org, linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v10 00/13] mm: Sub-section memory hotplug support Message-ID: <20190620170027.GA7126@linux> References: <156092349300.979959.17603710711957735135.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <156092349300.979959.17603710711957735135.stgit@dwillia2-desk3.amr.corp.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Tue, Jun 18, 2019 at 10:51:33PM -0700, Dan Williams wrote: > Changes since v9 [1]: > - Fix multiple issues related to the fact that pfn_valid() has > traditionally returned true for any pfn in an 'early' (onlined at > boot) section regardless of whether that pfn represented 'System RAM'. > Teach pfn_valid() to maintain its traditional behavior in the presence > of subsections. Specifically, subsection precision for pfn_valid() is > only considered for non-early / hot-plugged sections. (Qian) > > - Related to the first item introduce a SECTION_IS_EARLY > (->section_mem_map flag) to remove the existing hacks for determining > an early section by looking at whether the usemap was allocated from the > slab. > > - Kill off the EEXIST hackery in __add_pages(). It breaks > (arch_add_memory() false-positive) the detection of subsection > collisions reported by section_activate(). It is also obviated by > David's recent reworks to move the 'System RAM' request_region() earlier > in the add_memory() sequence(). > > - Switch to an arch-independent / static subsection-size of 2MB. > Otherwise, a per-arch subsection-size is a roadblock on the path to > persistent memory namespace compatibility across archs. (Jeff) > > - Update the changelog for "libnvdimm/pfn: Fix fsdax-mode namespace > info-block zero-fields" to clarify that the "Cc: stable" is only there > as safety measure for a distro that decides to backport "libnvdimm/pfn: > Stop padding pmem namespaces to section alignment", otherwise there is > no known bug exposure in older kernels. (Andrew) > > - Drop some redundant subsection checks (Oscar) > > - Collect some reviewed-bys > > [1]: https://lore.kernel.org/lkml/155977186863.2443951.9036044808311959913.stgit@dwillia2-desk3.amr.corp.intel.com/ Hi Dan, I am planning to give it a final review later tomorrow. Now that this work is settled, I took the chance to dust off and push my vmemmap-hotplug, and I am working on that right now. But I would definetely come back to this tomorrow. Thanks for the work -- Oscar Salvador SUSE L3