Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1575285pxb; Wed, 2 Feb 2022 07:59:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJxK6pNy0vQc/CvmSPaE6wNS1NpLzCUuvjftTccG/gHiZXq475KxszOEQXiX1SfXJZX/9mLy X-Received: by 2002:a05:6a00:843:: with SMTP id q3mr30133735pfk.0.1643817541145; Wed, 02 Feb 2022 07:59:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643817541; cv=none; d=google.com; s=arc-20160816; b=DBIX4+bRqeJxTqW9pYclhUSDt+DfX/Ti/bGjryixnwWnFdf1CxxkddG4Jdxe5N7oR+ 2ClXSwdRySALbR6F8D+6wF0Fdm8yrKVJ2J1XLg7YozVDvxBY0Is6XULqEascgTSyqmES wcAsugESbs1dZlSh0piE6lDSt7++7ekuBSFZ/AWA+OQI42si8r43JPPKWuc8lWV7bNoK rMp5KUVXALPB8exuyyrEzS7vLbsfb4LbIb3Th1e8ULZGiVyi7G1Mv/eQEBTWsbI3Xu4a TCTvn11yllwN+fcjxmP7TxmtvmusOYPUD98/rfTyQBvex0vthKy0wS0g776+i+hgA3ef V6Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=kYBByq3Zzj+Iaw3bMHZH5j2OnG+wKZuSP9VniKuuN0M=; b=RoBAfxY64bcL6FQQgNVx3bx6fh4VEmZ9x20eLE4A4ord3K9sq1uttibv30YlGF1d0t yCj3CA+YHTU+MYG2WCqqs05cOujBDhqPwpmRdjaMEEeeWeKRHZDaVElkUer0WkG5Kn2w 1cDs+FcGHS+/lCnzT9At31NuSV5aXurVMDS4Ao47H/LpFJrs6yZEeO0QqDEwmT3GEIhN VkjmDeQMKMeivuON/NCD+8kPw1Cnv/7Abq+zVYe3aY6UzHHyIxogufDi2UE4pmVk8nT8 JOIE/M/r1xOdaq2btrYDjP5/Bl/tLQktX/GkYT2WXu8/YrT4KIMomY3/LeWAfnFBeJtp 4srQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=GggLvrls; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id oo4si5894104pjb.102.2022.02.02.07.58.49; Wed, 02 Feb 2022 07:59:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=GggLvrls; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233800AbiBAHAs (ORCPT + 99 others); Tue, 1 Feb 2022 02:00:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231231AbiBAHAr (ORCPT ); Tue, 1 Feb 2022 02:00:47 -0500 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 17832C061714 for ; Mon, 31 Jan 2022 23:00:47 -0800 (PST) Received: by mail-ej1-x632.google.com with SMTP id s5so50786800ejx.2 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=7w73FTUI2eGqCh953izdjeNLrBrp8nNnLLPbK/tbt8DnVCqaKyKUr/FpDdpqYRwlD/ 5U+bf+dawgJJLyO1+pUyUIx5zsdIeuZWhcfRtwI+1s2c+Qe1WJOQzEEEWJ+v59UkL6w4 Qjp7k8HbrS/nXzEraU76F3d0s8ovrj+QA6jgFQLVPhz6hCxHyJ59CwvTxjQjyFL1YMx7 hGcU/uh7MtEYmKWiXQ2xDLVBag2wK+PhCMUkQX8QrsypAgfePe2PQ5Z324osDgby/LKI nmBTJnZV6aDTjfuYz3KhL2H6GpWY5J9BEGn+3Fyx3TJDJ/Z1bl3wNOlHTco0Ft5ASQfe bwLw== X-Gm-Message-State: AOAM532wTErHSl94O0Q3Zqq+p1PG+xTH26MUXg24wuMsHFwaZfHoFXdh SiQ9hh5S9Btk3ZXwD0RUZtw= 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) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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