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 1CAC1C433F5 for ; Thu, 27 Jan 2022 08:40:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B5006B0071; Thu, 27 Jan 2022 03:40:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 564B06B0072; Thu, 27 Jan 2022 03:40:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 42C256B0073; Thu, 27 Jan 2022 03:40:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay025.a.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 30FAC6B0071 for ; Thu, 27 Jan 2022 03:40:07 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DEDF22190B for ; Thu, 27 Jan 2022 08:40:06 +0000 (UTC) X-FDA: 79075419612.03.259518E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf15.hostedemail.com (Postfix) with ESMTP id 5392BA0005 for ; Thu, 27 Jan 2022 08:40:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643272805; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vfnWWKEVjGKb36aA96y+8vHW4NMLWf6mwas7AEDwyAs=; b=XF3PscJ2+1qztA9Oi2yXVgmB8A0p+PVd5UGZKCLRXucvLnw1iD8+N6o8OEGI0o5u2TYOSd 485CJeGHkDD5JZAcv4OCxYqb3K3N9uXJcQiHf/pQhVtxjwDwBGkKbsJLvFrPrUdR8b6ti1 H5Xc629qF5Djh6ajLj7I6vDECwT0YHg= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-275-A8ZHYBeaNkKGCPjpHXkb8Q-1; Thu, 27 Jan 2022 03:39:59 -0500 X-MC-Unique: A8ZHYBeaNkKGCPjpHXkb8Q-1 Received: by mail-ej1-f70.google.com with SMTP id v2-20020a1709062f0200b006a5f725efc1so979722eji.23 for ; Thu, 27 Jan 2022 00:39:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=vfnWWKEVjGKb36aA96y+8vHW4NMLWf6mwas7AEDwyAs=; b=nN9IaRaFO0f464P/AP8Wfe2Pe0dFrcp1H2X7pC9w/rs0S5uyq08vuYQKvIt5ekOtJz idjX5A8tz6+wHHR63aVg7Ys1wFCFtS2ardAadRWxethR9VDfEunej9zNNbUiiXipeZ6v phEwB4xCVjrNYmMZwDDvy8ywee7ofWCLDQDKWbqdWgoWjCiRUPxottC4x7xeW+0SEz5x ENcL24V2zNdlj7Xfswp5cSlVI6op3bC+yzDyO9jYZD/2faNJryy4n7W8SSvPglgoTphc KBv/vBIdudUeeCOf1fc4lA24WActLnLqr8yu3gNu3q7R++lQrQdnGTXooMm+NF8toIZC gLtA== X-Gm-Message-State: AOAM532aXg5Bgi9wsxLLZ0AcaAF8x7DT5jjpgyV7F+6llnQNQmn+w4bg UsaJrI0vY5PMjzACxaFJdR5An6ZzDcMqjdYMUjBWjVaBZiYFdVNXRCM50K0hz6hUu9w7SqZoLXD 2cka1bJEsYn8= X-Received: by 2002:a50:ed06:: with SMTP id j6mr2737794eds.16.1643272798162; Thu, 27 Jan 2022 00:39:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJwJZot5/alOLrnvU6fGCDgOxjmuFTxhkyvHAqTn45vj3OcrM7LhowN72mwxSsCfTAGmmI9gfw== X-Received: by 2002:a50:ed06:: with SMTP id j6mr2737777eds.16.1643272797871; Thu, 27 Jan 2022 00:39:57 -0800 (PST) Received: from ?IPV6:2003:cb:c70d:8300:4812:9d4f:6cd8:7f47? (p200300cbc70d830048129d4f6cd87f47.dip0.t-ipconnect.de. [2003:cb:c70d:8300:4812:9d4f:6cd8:7f47]) by smtp.gmail.com with ESMTPSA id p12sm8405760ejd.180.2022.01.27.00.39.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Jan 2022 00:39:57 -0800 (PST) Message-ID: Date: Thu, 27 Jan 2022 09:39:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 To: Wei Yang , akpm@linux-foundation.org, mgorman@techsingularity.net, mhocko@suse.com Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20220127012023.18095-1-richard.weiyang@gmail.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] mm/memory_hotplug: build zonelist for managed_zone In-Reply-To: <20220127012023.18095-1-richard.weiyang@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 5392BA0005 X-Stat-Signature: wrfjhagsk834acn7ropyyhm5zrytwyoh Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XF3PscJ2; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf15.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-Rspam-User: nil X-HE-Tag: 1643272806-738026 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 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(). -- Thanks, David / dhildenb