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=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 24DAEC55189 for ; Wed, 22 Apr 2020 08:21:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E294B20663 for ; Wed, 22 Apr 2020 08:21:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E294B20663 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7EF4F8E0006; Wed, 22 Apr 2020 04:21:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A0058E0003; Wed, 22 Apr 2020 04:21:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68EAF8E0006; Wed, 22 Apr 2020 04:21:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id 4EE168E0003 for ; Wed, 22 Apr 2020 04:21:05 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0ABF2246B for ; Wed, 22 Apr 2020 08:21:05 +0000 (UTC) X-FDA: 76734795690.03.hope58_60bc08bde834a X-HE-Tag: hope58_60bc08bde834a X-Filterd-Recvd-Size: 5386 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Apr 2020 08:21:04 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id y24so1262912wma.4 for ; Wed, 22 Apr 2020 01:21:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5NU5ZhAJHq6ciQrPGIfc8KggoL6wwkS48uukTc3+gvE=; b=ls6xRM8rQVOfw3WTgvKNrIsUfFk1Rrgxyh5pU3zrP9o7Nmx+BVY+jD0qJ/NiTuc9HH +4ea80cx/Sx38gS60a5lwk50ZNfzOaNTS/U/4Gl3kZtwt10BuBXvJSsYMcBedl4JSZRe ThR4KGX+Vx+N+v6JO7W2GHhRitDcpIHdyjvqKxK41JgmM69X+mdOQgPpOLxikjFDanRt wJEiBPAOv+4GOaZMqVy5rILyX16oyMyD3nibZJWDIxRJpfSfP9dq+Ff3Uz7aEnLT4LQy 2bhejyQa4dQBdJjsfE2CAIAYM7HdUGZZAZCZpo9hDUcM9mirEXvchqHNwMqhd6zvkmii oYFw== X-Gm-Message-State: AGi0PuZsNGtZDFxtH5h1C6X3Tp3x23o+PeqNjH/CmdJeFYsKdJsyt4YH acrtv3KrY50xIsGSlntHg+8= X-Google-Smtp-Source: APiQypIahp8XtYzcQptvFeNTn34PdqiiYT9KTGBHLyPfNL1QcREQrptbYD4Ao0S0wxPn6ghGhgl8KQ== X-Received: by 2002:a1c:4346:: with SMTP id q67mr9023354wma.162.1587543663505; Wed, 22 Apr 2020 01:21:03 -0700 (PDT) Received: from localhost (ip-37-188-130-62.eurotel.cz. [37.188.130.62]) by smtp.gmail.com with ESMTPSA id f7sm7011365wrt.10.2020.04.22.01.21.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Apr 2020 01:21:02 -0700 (PDT) Date: Wed, 22 Apr 2020 10:21:01 +0200 From: Michal Hocko To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Baoquan He , Oscar Salvador , Pankaj Gupta Subject: Re: [PATCH RFC 1/2] mm/memory_hotplug: no need to init new pgdat with node_start_pfn Message-ID: <20200422082101.GC30312@dhcp22.suse.cz> References: <20200416104707.20219-1-david@redhat.com> <20200416104707.20219-2-david@redhat.com> <20200421123011.GE27314@dhcp22.suse.cz> <20200421125250.GG27314@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue 21-04-20 15:06:20, David Hildenbrand wrote: > On 21.04.20 14:52, Michal Hocko wrote: > > On Tue 21-04-20 14:35:12, David Hildenbrand wrote: > >> On 21.04.20 14:30, Michal Hocko wrote: > >>> Sorry for the late reply > >>> > >>> On Thu 16-04-20 12:47:06, David Hildenbrand wrote: > >>>> A hotadded node/pgdat will span no pages at all, until memory is moved to > >>>> the zone/node via move_pfn_range_to_zone() -> resize_pgdat_range - e.g., > >>>> when onlining memory blocks. We don't have to initialize the > >>>> node_start_pfn to the memory we are adding. > >>> > >>> You are right that the node is empty at this phase but that is already > >>> reflected by zero present pages (hmm, I do not see spanned pages to be > >>> set 0 though). What I am missing here is why this is an improvement. The > >>> new node is already visible here and I do not see why we hide the > >>> information we already know. > >> > >> "information we already know" - no, not before we online the memory. > > > > Is this really the case? All add_memory_resource users operate on a > > physical memory range. > > Having the first add_memory() to magically set node_start_pfn of a hotplugged > node isn't dangerous, I think we agree on that. It's just completely > unnecessary here and at least left me confused why this is needed at all- > because the node start/end pfn is only really touched when > onlining/offlining memory (when resizing the zone and the pgdat). I do not see any specific problem. It just feels odd to ignore the start pfn when we have that information. I am little bit worried that this might kick back. E.g. say we start using the memmaps from the hotplugged memory then the initial part of the node will never get online and we would have memmaps outside of the node span. I do not see an immediate problem except for the feeling this is odd. That being said I will shut up now and leave it alone. [...] > > Btw. one thing that I have in my notes, I was never able to actually > > test the no numa node case. Because I have always been testing with node > > being allocated during the boot. Do you have any way to trigger this > > path? > > Sure, here is my test case > > #! /bin/bash > sudo qemu-system-x86_64 \ > --enable-kvm \ > -m 4G,maxmem=20G,slots=2 \ > -smp sockets=2,cores=2 \ > -numa node,nodeid=0,cpus=0-1,mem=4G -numa node,nodeid=1,mem=0G \ I have been using a similar command line NUMA_ONE_MEMORY_LESS_NODE="-numa node,mem=2G -numa node,mem=0G" which gets appended to the qemu cmdline. I have always thought that this would allocate pgdat for node 1 though. I have checked that again now and dmesg doesn't point to node 1 anywhere. Thanks! -- Michal Hocko SUSE Labs