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 48D25C433EF for ; Thu, 3 Feb 2022 09:25:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C6F478D0138; Thu, 3 Feb 2022 04:25:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C1F5D8D0124; Thu, 3 Feb 2022 04:25:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AE6B58D0138; Thu, 3 Feb 2022 04:25:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0173.hostedemail.com [216.40.44.173]) by kanga.kvack.org (Postfix) with ESMTP id 9F1018D0124 for ; Thu, 3 Feb 2022 04:25:56 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 551C5181F10FF for ; Thu, 3 Feb 2022 09:25:56 +0000 (UTC) X-FDA: 79100936712.29.FAE834B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf15.hostedemail.com (Postfix) with ESMTP id CB19EA0002 for ; Thu, 3 Feb 2022 09:25:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643880355; 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=HGSSgLbVI6aAIEB9+yonqjHxMTOVKzKIbf4r9so+9F0=; b=Hfrce/d97s8jd41JKdtKnRplrZaqr9WUD/a698RMim6EXehTvOrQUneEmVPOmm299q75Am /xWTR98nw/Hf4kpC9Ex7nfA2DmRsQAxFsj5emz6uFtG0sAE9RrpKN3ofdQS4Wo4v9dpE5C o4+ovSGrAkTTjiU0Ew3eDZ1jnJ8AlkU= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-638-7Dn5wPS_MqWxaeq1aX9WtQ-1; Thu, 03 Feb 2022 04:25:54 -0500 X-MC-Unique: 7Dn5wPS_MqWxaeq1aX9WtQ-1 Received: by mail-wm1-f70.google.com with SMTP id w5-20020a1cf605000000b00354d2d83490so518704wmc.4 for ; Thu, 03 Feb 2022 01:25:54 -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=HGSSgLbVI6aAIEB9+yonqjHxMTOVKzKIbf4r9so+9F0=; b=QCWWteflByaqQnoiIbo7N2df3lw6sXJw4xLWwUmvbv/6WG06i3ahn4q3fsrD7MkmdW /50LBbpMFESnQxL3JioLbkm1qqTbeH/z3Rr7MbbFy/PcXZe88gI29wMslq9k1ZiwKtzx 12iQjOi6pvuIYjw2Q/Zrf2oXBgLhsVaW0R24V1wZc21R+vyR07DA72q5yiD01V9Df79c qJNVLGGd2UIa3BAWMdkmKvGL+YduIEq71ZiigeATc5ZchgANo62gKha5B8R+Jlgf49aQ vGsjstYfJjWpo8pIj7tED4wA5tRvaV8IId5QDtYOU9abgNjIiTtLhxFMh+g5Mtu9w7q4 JEpw== X-Gm-Message-State: AOAM533bzu6CW45durDS0KOmGudCyalM8FTbFSg3Q/U3gukTkY1sxNeD VKsgNRu+2z10SZiZo7Z42VhaS7Dnil0Wf5KKUcsCP5G6plgJ/K8+715HNtj4ZLygK1uRLQjkW+I rMrqP3+3mvBw= X-Received: by 2002:a5d:544c:: with SMTP id w12mr27664834wrv.357.1643880353016; Thu, 03 Feb 2022 01:25:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJz3d2LnuGTJxZPrIEIW6ESYD9bj3fX2gcGpKKuKvYuOgKefaDHuBKXCUZcq9WOaBptIp61dUw== X-Received: by 2002:a5d:544c:: with SMTP id w12mr27664817wrv.357.1643880352801; Thu, 03 Feb 2022 01:25:52 -0800 (PST) Received: from ?IPV6:2003:d8:2f11:9700:838c:3860:6500:5284? (p200300d82f119700838c386065005284.dip0.t-ipconnect.de. [2003:d8:2f11:9700:838c:3860:6500:5284]) by smtp.gmail.com with ESMTPSA id g20sm9382448wmq.9.2022.02.03.01.25.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Feb 2022 01:25:52 -0800 (PST) Message-ID: <530d1ca4-6e05-b237-e0a9-c43d61767c4d@redhat.com> Date: Thu, 3 Feb 2022 10:25:51 +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, mhocko@suse.com, mgorman@techsingularity.net Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20220203020022.3044-1-richard.weiyang@gmail.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] mm/page_alloc: add zone to zonelist if populated In-Reply-To: <20220203020022.3044-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 Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Hfrce/d9"; spf=none (imf15.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: nil X-Rspamd-Queue-Id: CB19EA0002 X-Stat-Signature: gk9b4bh8rnf41u1mmdpgqfsu6f94hz7x X-Rspamd-Server: rspam12 X-HE-Tag: 1643880355-369588 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 03.02.22 03:00, Wei Yang wrote: > During memory hotplug, when online/offline a zone, we need to rebuild > the zonelist for all nodes. Current behavior would lose a valid zone in > zonelist since only pick up managed_zone. > > There are two cases for a zone with memory but still !managed. > > * all pages were allocated via memblock > * all pages were taken by ballooning / virtio-mem > > This state maybe temporary, since both of them may release some memory. > Then it end up with a managed zone not in zonelist. > > This is introduced in 'commit 6aa303defb74 ("mm, vmscan: only allocate > and reclaim from zones with pages managed by the buddy allocator")'. > This patch restore the behavior. > > Signed-off-by: Wei Yang > CC: Mel Gorman > CC: David Hildenbrand > Fixes: 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones with pages managed by the buddy allocator") That commit mentions that there used to be some ppc64 cases with fadump where it might have been a real problem. Unfortunately, that commit doesn't really tell what the performance implications are. We'd have to know how many "permanent memblock" allocations we have, that can never get freed. > --- > mm/page_alloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index de15021a2887..b433a57ee76f 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -6092,7 +6092,7 @@ static int build_zonerefs_node(pg_data_t *pgdat, struct zoneref *zonerefs) > do { > zone_type--; > zone = pgdat->node_zones + zone_type; > - if (managed_zone(zone)) { > + if (populated_zone(zone)) { > zoneref_set_zone(zone, &zonerefs[nr_zones++]); > check_highest_zone(zone_type); > } The comment above the function also expresses that "Add all populated zones of a node to the zonelist.", so one way or the other, that should be made consistent. -- Thanks, David / dhildenb