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 E030AC433EF for ; Thu, 7 Apr 2022 12:15:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3CF946B0073; Thu, 7 Apr 2022 08:14:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 357CA6B0074; Thu, 7 Apr 2022 08:14:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F9666B0075; Thu, 7 Apr 2022 08:14:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0240.hostedemail.com [216.40.44.240]) by kanga.kvack.org (Postfix) with ESMTP id 11F916B0073 for ; Thu, 7 Apr 2022 08:14:59 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C13461842BE2C for ; Thu, 7 Apr 2022 12:14:48 +0000 (UTC) X-FDA: 79329976656.23.768CE2F Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf30.hostedemail.com (Postfix) with ESMTP id 1D01380003 for ; Thu, 7 Apr 2022 12:14:47 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id D5A2F210EA; Thu, 7 Apr 2022 12:14:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1649333686; h=from:from:reply-to: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=PtNVmE1emwW/zSfcFurzs/NtccDx0eiUPTowKoz+RNk=; b=QvJvZjV3tnz+F/+YT8CTV+iCfToW0qpQ1YrYkaoPuNKKBfsYg3NyFAmcfqk67894y2NESO gIq26lohcEJChJElvQSTvMjfREMEIQhWvtmPFJVWAP1l0iEiHuh7wEkgEKqkZrSkRUiI8G 0hVaK9HWxIE7RMwIqk4KMKL+YLHFRtE= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 9F5F8A3B82; Thu, 7 Apr 2022 12:14:46 +0000 (UTC) Date: Thu, 7 Apr 2022 14:14:46 +0200 From: Michal Hocko To: Juergen Gross Cc: xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , stable@vger.kernel.org, Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= , Mel Gorman Subject: Re: [PATCH v2] mm, page_alloc: fix build_zonerefs_node() Message-ID: References: <20220407120637.9035-1-jgross@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20220407120637.9035-1-jgross@suse.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 1D01380003 X-Stat-Signature: y54p14zhmx8bezpntq1cjif1pzbtbso8 X-Rspam-User: Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=QvJvZjV3; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf30.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-HE-Tag: 1649333687-882399 Content-Transfer-Encoding: quoted-printable 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: [CC Mel] On Thu 07-04-22 14:06:37, Juergen Gross wrote: > Since commit 6aa303defb74 ("mm, vmscan: only allocate and reclaim from > zones with pages managed by the buddy allocator") only zones with free > memory are included in a built zonelist. This is problematic when e.g. > all memory of a zone has been ballooned out when zonelists are being > rebuilt. >=20 > The decision whether to rebuild the zonelists when onlining new memory > is done based on populated_zone() returning 0 for the zone the memory > will be added to. The new zone is added to the zonelists only, if it > has free memory pages (managed_zone() returns a non-zero value) after > the memory has been onlined. This implies, that onlining memory will > always free the added pages to the allocator immediately, but this is > not true in all cases: when e.g. running as a Xen guest the onlined > new memory will be added only to the ballooned memory list, it will be > freed only when the guest is being ballooned up afterwards. Thanks this is much more clearer! =20 > Another problem with using managed_zone() for the decision whether a > zone is being added to the zonelists is, that a zone with all memory > used will in fact be removed from all zonelists in case the zonelists > happen to be rebuilt. >=20 > Use populated_zone() when building a zonelist as it has been done > before that commit. >=20 > Cc: stable@vger.kernel.org > Fixes: 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones = with pages managed by the buddy allocator") > Reported-by: Marek Marczykowski-G=F3recki > Signed-off-by: Juergen Gross > Acked-by: Michal Hocko > --- > V2: > - updated commit message (Michal Hocko) > --- > mm/page_alloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index bdc8f60ae462..3d0662af3289 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -6128,7 +6128,7 @@ static int build_zonerefs_node(pg_data_t *pgdat, = struct zoneref *zonerefs) > do { > zone_type--; > zone =3D 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); > } > --=20 > 2.34.1 --=20 Michal Hocko SUSE Labs