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 E51C2C433EF for ; Sat, 29 Jan 2022 00:27:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F2FD6B0075; Fri, 28 Jan 2022 19:27:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A1E66B00DC; Fri, 28 Jan 2022 19:27:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 542B56B00DE; Fri, 28 Jan 2022 19:27:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0003.hostedemail.com [216.40.44.3]) by kanga.kvack.org (Postfix) with ESMTP id 473486B0075 for ; Fri, 28 Jan 2022 19:27:41 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1472D97919 for ; Sat, 29 Jan 2022 00:27:41 +0000 (UTC) X-FDA: 79081436322.12.CCE5AC7 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf29.hostedemail.com (Postfix) with ESMTP id A97CA120005 for ; Sat, 29 Jan 2022 00:27:40 +0000 (UTC) Received: by mail-ed1-f54.google.com with SMTP id p12so13150790edq.9 for ; Fri, 28 Jan 2022 16:27:40 -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=DzlKGdu63oR5Np89nKMxqPFykzScyAGBA+0JycwAsUY=; b=e5pWhHvhSjsub44oqXp71+F6yp3o0iasEVgUl3tMiNyMhFZh6PPZur6H+E8xPpVXPu xvPloJ6qhhQWB0QuSpGR4JogJcMY7a/MT3ex3V1O5weKwVwhP3a1hQ9yXAo1suVQJksR Jv4kvfYKBAQTe2Z5kK37ecw3EbiwRdxIUefJ/WTcOrQ+XqTmvXDxZU7v9NSa50UPAGTU n3P9Cmm0EwPJbeVFH6St8toBJetsFQaF+QR3N4DuKu3jZhhXgcV2nGDNzR0LWMieQHSF 9IewkQcVt0WV3WTwo39GvtxwoNdNxfp/o1JYpoi4BTzxFYjJagBBN6c0uU9FWOTF5Fq6 L02A== 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=DzlKGdu63oR5Np89nKMxqPFykzScyAGBA+0JycwAsUY=; b=lw+Di86fKeQutQ7HIIuPv+FScIi34NnjI+sJz9R2NGJ1Xrn7oS+mU9ViUhzAlNE2Lc 2r+VdlprmOaNv7MKw2Q5H87mvxdBLGZHqbswEV9s64HFrq5DDkoipRLGpRjOaEat5rb1 lTRUDiKMEUm2Dv9JAwUdEBPnKhMeAhITNkDAhlKeIHdqMe+geKAu3m/aleWzuIgCYy/6 z0ixLTkAWkKvKdUjJBgnGX2mrvCeliHqgHDkkRkilwPzSjABe3P4Kp0siKH3f1wj0y0b eT+PsMwEQqr1SJELvYBISMzgLevIeXwSJXSF/WzHGaM9kz3Iy/CTjigIBN42uCkWXcee Td6w== X-Gm-Message-State: AOAM530r5o3cls81bqYYP2Oh+0t9CQQC9Gd5Tge4cUAukCpdGOLpiUu6 u562bca0DRXro8khou4uA+w= X-Google-Smtp-Source: ABdhPJwX8z9eqiBRQJF5SXr/wIsd4M54RJcw2Tp7MzJeoErFVPYzTqy3eEgcJpyLS8RJuaaWUWKQLA== X-Received: by 2002:a05:6402:1ac5:: with SMTP id ba5mr10591620edb.337.1643416059486; Fri, 28 Jan 2022 16:27:39 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id d16sm10385885ejy.135.2022.01.28.16.27.39 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 28 Jan 2022 16:27:39 -0800 (PST) Date: Sat, 29 Jan 2022 00:27:38 +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: <20220129002738.ofoewhgb4mwfwqfj@master> Reply-To: Wei Yang References: <20220127012023.18095-1-richard.weiyang@gmail.com> 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-Stat-Signature: xrb1k8d737aecbfiz1trba8667uui54r X-Rspam-User: nil Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=e5pWhHvh; spf=pass (imf29.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: A97CA120005 X-HE-Tag: 1643416060-132287 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 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? >-- >Thanks, > >David / dhildenb -- Wei Yang Help you, Help me