Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp420619pxb; Thu, 7 Apr 2022 08:59:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy7cInRX+SjZS5Yr92XNh4Oqd8KiufgHK4bQbxPyiIBS0vIFpLm3HDs74JL5HrbiDwczyKR X-Received: by 2002:a17:902:ec83:b0:154:7cee:7722 with SMTP id x3-20020a170902ec8300b001547cee7722mr14705727plg.96.1649347199408; Thu, 07 Apr 2022 08:59:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649347199; cv=none; d=google.com; s=arc-20160816; b=XO49Re0xdw2qEj004NZZz0SCOQ95k/h+S3+XDmUTp6z2NlN3xOiqC9qtQxgjzVi3DV O/MsxEaok/JUUW07HglFuJa0eZni6eYPEkQtofottMKGcaupZeG6zCN74NmC72cBRkA2 t+/M2QFve+9egEdpWryV4nahg72RTIVe+Alpt23JHgLPJueVQ2uWUo7281ijidvIDocX 84m1y1XI29OcoUzXRYuSOvAUmklU4G+8agSQup/ygltDazX2l/BGH0N86w4OU6NDz5uR GzOwKBoJt1dKFH+qYP/ozpFHWkMeBJ2YVXGiJsdXvNzblHEypOxLBrpLyqjJJkGDUT5o fWcg== 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:message-id:subject:cc:to:from:date; bh=J3p5Nr/80rMfh9lb6+A5HOZ4oTpKk9gqJozH41m19EE=; b=WYNDTlA1cfxGvlMBSUtHz3SDpsVdRo+SEfJ7S+G57XxzQibYjssgFdwH++KRrwaCpf 9/k1vAMdKr29Y2bJMSgmSP4Lm3WUSB8XZNTnAQwL+e9Qye0VklmSruTRCqsvJMVmdSaq sK/hihkIcBPS1GsQ2LXYBdY1p4kWD7g71m5oO9NkFU1hqoy9jXOchRea2hU1H61IjE2A b0PObauhvNG+AYKDEszxDvUcu61RUScQhORxjAp7DS9iEbbpJVE9TVbN05YLQI4lAXtt ypuosRguTMP5qBKx60Qcz7YE4ILCVu3JpYvgpBBFMDOJVKOkqEGgGKABK3AtfW22iL6G mwaw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v7-20020a63bf07000000b0039854fb2001si19968463pgf.496.2022.04.07.08.58.39; Thu, 07 Apr 2022 08:59:59 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245217AbiDGMfE (ORCPT + 99 others); Thu, 7 Apr 2022 08:35:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245258AbiDGMey (ORCPT ); Thu, 7 Apr 2022 08:34:54 -0400 Received: from outbound-smtp10.blacknight.com (outbound-smtp10.blacknight.com [46.22.139.15]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B684D1403E3 for ; Thu, 7 Apr 2022 05:32:53 -0700 (PDT) Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp10.blacknight.com (Postfix) with ESMTPS id 26EF81C37BE for ; Thu, 7 Apr 2022 13:32:52 +0100 (IST) Received: (qmail 22167 invoked from network); 7 Apr 2022 12:32:51 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.17.223]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 7 Apr 2022 12:32:51 -0000 Date: Thu, 7 Apr 2022 13:32:44 +0100 From: Mel Gorman To: Juergen Gross Cc: Michal Hocko , xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , stable@vger.kernel.org, Marek Marczykowski-G?recki , Mel Gorman Subject: Re: [PATCH] mm, page_alloc: fix build_zonerefs_node() Message-ID: <20220407115414.GA4148@techsingularity.net> References: <20220407093221.1090-1-jgross@suse.com> <5e97a7f5-1fc9-d0b4-006e-6894d5653c06@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <5e97a7f5-1fc9-d0b4-006e-6894d5653c06@suse.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 07, 2022 at 01:17:19PM +0200, Juergen Gross wrote: > On 07.04.22 13:07, Michal Hocko wrote: > > On Thu 07-04-22 12:45:41, Juergen Gross wrote: > > > On 07.04.22 12:34, Michal Hocko wrote: > > > > Ccing Mel > > > > > > > > On Thu 07-04-22 11:32:21, Juergen Gross wrote: > > > > > Since commit 9d3be21bf9c0 ("mm, page_alloc: simplify zonelist > > > > > initialization") 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. > > > > > > > > What is the actual problem there? > > > > > > When running as Xen guest new hotplugged memory will not be onlined > > > automatically, but only on special request. This is done in order to > > > support adding e.g. the possibility to use another GB of memory, while > > > adding only a part of that memory initially. > > > > > > In case adding that memory is populating a new zone, the page allocator > > > won't be able to use this memory when it is onlined, as the zone wasn't > > > added to the zonelist, due to managed_zone() returning 0. > > > > How is that memory onlined? Because "regular" onlining (online_pages()) > > does rebuild zonelists if their zone hasn't been populated before. > > The Xen balloon driver has an own callback for onlining pages. The pages > are just added to the ballooned-out page list without handing them to the > allocator. This is done only when the guest is ballooned up. > Is this new behaviour? I ask because keeping !managed_zones out of the zonelist and reclaim paths and the behaviour makes sense. Elsewhere you state "zone can always happen to have no free memory left" and this is true but it's usually a transient event. The difference between a populated vs managed zone is usually permanent event where no memory will ever be placed on the buddy lists because the memory was reserved early in boot or a similar reason. The patch is probably harmless but it has the potential to waste CPUs allocating or reclaiming from zones that will never succeed. -- Mel Gorman SUSE Labs