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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1687CC433F5 for ; Tue, 1 Feb 2022 07:00:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7986B8D0055; Tue, 1 Feb 2022 02:00:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 720BC8D0054; Tue, 1 Feb 2022 02:00:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C1278D0055; Tue, 1 Feb 2022 02:00:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0144.hostedemail.com [216.40.44.144]) by kanga.kvack.org (Postfix) with ESMTP id 49A748D0054 for ; Tue, 1 Feb 2022 02:00:48 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id F110098796 for ; Tue, 1 Feb 2022 07:00:47 +0000 (UTC) X-FDA: 79093313334.25.EC1AAF4 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by imf29.hostedemail.com (Postfix) with ESMTP id 9C370120011 for ; Tue, 1 Feb 2022 07:00:46 +0000 (UTC) Received: by mail-ej1-f52.google.com with SMTP id s13so51156899ejy.3 for ; Mon, 31 Jan 2022 23:00:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=kYBByq3Zzj+Iaw3bMHZH5j2OnG+wKZuSP9VniKuuN0M=; b=GggLvrlsjF9yszwZd+41yT8BpCPmBuOA8YQqQjjhB02p/bwEeQa0rXfqszR7fD/AfL 0e/LaDAXm6ykU/uZFRCwT8U9GOwPUAfTghf9a+vGJzqAYi8vKPNe2iqDxXogdMnLGLhi W8iiAyMkY+tuUnAzG4v0kS6fzzanli6F+ymd6cW3544A8CNXKs0My596iH9cbg/MghhB Wv7Y4wVuH6QuSxDFLnPfADo/zUATBBGvx9IUoJLsaPW00R7hInHqZfoFG3Q7Eqz8PEJd IbmTuqOgEiN1/9kRWIm/OmKT39yebpAS89RUSFXEywyjcv3HoXnx4EO3uKVQTm4RvOdZ sEXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=kYBByq3Zzj+Iaw3bMHZH5j2OnG+wKZuSP9VniKuuN0M=; b=GOmpBWNHw87I1crKoBv0zXaFVZa/BQF1gKo6dbmJspVPxsR9B5SH/wPYdNIk8Ia/+z B+Umym5/bbva4ffCBr02m6RLymhIMzStRak4oWJOt3/44/8OqAgQeAiuzGf7RnFDkmrX irAMp0FaUKNtf20Y+dkLyZWCBohPBZrrxygxZ554glX5Cj5w8MyZz43FsQN/HAx5thpm Qte8UecZTFeiLQmvVenLCnRpgRzaEBrJXP6zFNvSagPy2/M1Z9oarA6etf2bVB3Ldwkj qNn5B0GP8Il7ZkvLBxJXsZ9JPkGHxwxKw5qXlovwIJL6VFnu2Ve9ifTgpLmYMZcH4lAy 1yyQ== X-Gm-Message-State: AOAM532Eg7o1Ww2woekYE/ZjCtO3WE1MNgBxzvg/lRQcXAx7JoeshSQo JxVxZVw4bZtSeEqE1AM2IZM= X-Google-Smtp-Source: ABdhPJzcVUNVqP+ebuiVF2wCV/dZPnvf7j4L3m9+AM1uf03hk765Ney8aulwI7NSVDglN9Vrj/eRCA== X-Received: by 2002:a17:907:96aa:: with SMTP id hd42mr11057655ejc.13.1643698845447; Mon, 31 Jan 2022 23:00:45 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id z19sm14311826eji.87.2022.01.31.23.00.44 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 31 Jan 2022 23:00:44 -0800 (PST) Date: Tue, 1 Feb 2022 07:00:44 +0000 From: Wei Yang To: David Hildenbrand Cc: Wei Yang , akpm@linux-foundation.org, mgorman@techsingularity.net, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/memory_hotplug: build zonelist for managed_zone Message-ID: <20220201070044.zbm3obsoimhz3xd3@master> Reply-To: Wei Yang References: <20220127012023.18095-1-richard.weiyang@gmail.com> <20220129002738.ofoewhgb4mwfwqfj@master> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9C370120011 X-Stat-Signature: pznrxbfzx4bjoza5p97o61y4fbe6rjuj X-Rspam-User: nil Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GggLvrls; spf=pass (imf29.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1643698846-638091 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 Mon, Jan 31, 2022 at 11:53:36AM +0100, David Hildenbrand wrote: >On 29.01.22 01:27, Wei Yang wrote: >> On Thu, Jan 27, 2022 at 09:39:56AM +0100, David Hildenbrand wrote: >>> On 27.01.22 02:20, Wei Yang wrote: >>>> During memory hotplug, when online/offline a zone, we need to rebuild >>>> the zonelist for all node. There are two checks to decide whether a zone >>>> would be added to zonelist: >>>> >>>> * one in online_pages/offline_pages to decide necessity >>>> * one in build_zonerefs_node to do real add >>>> >>>> Currently we use different criteria at these two places, which is >>>> different from the original behavior. >>>> >>>> Originally during memory hotplug, zonelist is re-built when zone hasn't >>>> been populated. This in introduced in 'commit 6811378e7d8b ("[PATCH] >>>> wait_table and zonelist initializing for memory hotadd: update zonelists")'. >>>> And at that moment, build_zonelists_node() also use populated_zone() to >>>> decide whether the zone should be added to zonelist. >>>> >>>> While in 'commit 6aa303defb74 ("mm, vmscan: only allocate and reclaim >>>> from zones with pages managed by the buddy allocator")', >>>> build_zonelists_node() changed to use managed_zone() to add zonelist. >>>> But we still use populated_zone() to decide the necessity. >>>> >>>> This patch restore the original behavior by using the same criteria to >>>> add a zone in zonelist during memory hotplug. >>>> >>>> Signed-off-by: Wei Yang >>>> Fixes: 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones with pages managed by the buddy allocator") >>>> CC: Mel Gorman >>>> --- >>>> mm/memory_hotplug.c | 6 +++--- >>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c >>>> index 2a9627dc784c..8f1906b33937 100644 >>>> --- a/mm/memory_hotplug.c >>>> +++ b/mm/memory_hotplug.c >>>> @@ -1102,11 +1102,11 @@ int __ref online_pages(unsigned long pfn, unsigned long nr_pages, >>>> spin_unlock_irqrestore(&zone->lock, flags); >>>> >>>> /* >>>> - * If this zone is not populated, then it is not in zonelist. >>>> + * If this zone is not managed, then it is not in zonelist. >>>> * This means the page allocator ignores this zone. >>>> * So, zonelist must be updated after online. >>>> */ >>>> - if (!populated_zone(zone)) { >>>> + if (!managed_zone(zone)) { >>>> need_zonelists_rebuild = 1; >>>> setup_zone_pageset(zone); >>>> } >>>> @@ -1985,7 +1985,7 @@ int __ref offline_pages(unsigned long start_pfn, unsigned long nr_pages, >>>> /* reinitialise watermarks and update pcp limits */ >>>> init_per_zone_wmark_min(); >>>> >>>> - if (!populated_zone(zone)) { >>>> + if (!managed_zone(zone)) { >>>> zone_pcp_reset(zone); >>>> build_all_zonelists(NULL); >>>> } >>> >>> A note that managed_zone() is a moving target w.r.t. memory ballooning. >>> In extreme cases, we can have whole zones (temporarily) be completely >>> !managed for that reason. >>> >>> IMHO memory hot(un)plug is usually the wrong place to check for >>> managed_zone(), it cares about populated_zone(). >>> >> >> So we need to check populated_zone when building zonelist? > >I think the issue is that > >a) We can have zones without any managed pages put present page during >boot, for example, if all pages in the zone were allocated via memblock. > >b) We can have zones without any managed pages temporarily -- extreme >cases of memory ballooning / virtio-mem. > > >I tend to think that populated_zone() might actually be the right check >whenever building a zonelist. Because even in case of a) we might end up >freeing a memblock allocation later, suddenly having free pages in such >a zone, but the zone not in any zonelist. I agree with you for this point. > >-- >Thanks, > >David / dhildenb -- Wei Yang Help you, Help me