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 F1B5DC021B8 for ; Wed, 26 Feb 2025 11:01:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5EB286B0083; Wed, 26 Feb 2025 06:01:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 59AAE6B0096; Wed, 26 Feb 2025 06:01:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 46244280001; Wed, 26 Feb 2025 06:01:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 2A14A6B0083 for ; Wed, 26 Feb 2025 06:01:02 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B98248121E for ; Wed, 26 Feb 2025 11:01:01 +0000 (UTC) X-FDA: 83161803522.15.113594B Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf29.hostedemail.com (Postfix) with ESMTP id 5BC5A12001B for ; Wed, 26 Feb 2025 11:00:59 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=YRnBKG54; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740567659; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=P4cimuL6QggB7FtdnHhrYIP2EOrboefYvnAfBmaj4Pk=; b=vm1znfg6Hiib1yJlBjCC1FhZP4lzrf9W7HMN5YDiXbY8lvRCNlqLaOvWEf9h2xSu9M+6pk Eal1j6FJfeBLR7h7cI6V3SJrAo+JE4Sry9hC1sLxoxYsvDZIQCOvXQH94JozbsvpRhDYes oTGJBB6y+YXMHz9aU+4llQmVy/rapHc= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=YRnBKG54; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740567659; a=rsa-sha256; cv=none; b=rrPrqh7LQmwH5E0eNz1+sMcSiLihPuptPO+G3g4UoXeqtHko4+mtmCKkIDZmf4OhWHD8Dw QPHwRQYFUYr9ZUfB9wymcVX1zf9aYA79MaWijCsyothSulltoTbCupJZWbNeuvNO4YGlrn styOurd79LZ2s3mbh2mmXP0up1ZLHho= Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-546202d633dso6548565e87.2 for ; Wed, 26 Feb 2025 03:00:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1740567657; x=1741172457; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=P4cimuL6QggB7FtdnHhrYIP2EOrboefYvnAfBmaj4Pk=; b=YRnBKG54jGpejuRScv6KFUxXeVNa7I+48xEb+CfwqrCl8vNOlziLynRV1rT8S3zKJZ CnR+L1klDipbt6udScNNbQK1RtosM7O8oBN2LAonhWSa4AKCtrGiW084J40RiFgA9gMg YNeLIH25IakttpucwSezlx0PBgn+APTpqxxs6DLuNPI7cRilBoWSUkatGE4KIS39fECY ncv0WcsS/rBU9/T542/oMK62V/TlIpAViSEwPBgIGwGw5xrYhMzx4rUtjLU32z2sFfJY hoyW5VjhvCsUxFVdzV5mhzwxKufC7dxEqopwgSmNJ163Xgchx5qTNJwfY6z3payeUhsn xTeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740567657; x=1741172457; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=P4cimuL6QggB7FtdnHhrYIP2EOrboefYvnAfBmaj4Pk=; b=JSNqfsr/CVm2+Y9D7nN74GFOI+iLeqxRc9pAe8ClzkZj4YUe5LCs6+TnSn/pVJNsJU QnmSX/LhScj3K6Ytpug9BIYDQO/SZUi9z6pH2gdxLjstvfd+5hDZ3XXWVXmxXjemVSap 9f4hnBbjV8CGhIx52UNRXFxdLNUUzWGSuHwv9HxGrHoqrGRGBYv+Eib7relZmfNfLfEr UFkiz+zOWmXC0EXtYnw9iU5Mvp1IYSkUAYkWjuBe6uAvQBJ9k2WpVECUkIdkRac4/DmT gIb+6mut5Gd6k0CToakQ+K4skgT359sI4z5i/UoNBNFPpHbGqVi97O/HX9FIIK0alu0a YuAg== X-Forwarded-Encrypted: i=1; AJvYcCVbusSQ6d16khkOpP+VO8MMHDJHs402KX029kgcO1Dc2TpWZBd8/oFRrKFvTcsqpPrPX8KX8wKiQg==@kvack.org X-Gm-Message-State: AOJu0YwFe2vCAvAahwicJ1thsQOpc/L0ZiQRWO0QhUzgrsAHCVKdWdhK lirW/VcsujZ25Ra5h8FIIK203X5ycse23dX1sJJh6m/oyLtsZLvqrdL3TLUvSGM= X-Gm-Gg: ASbGncupqpJG0QB7bHImdEYbepZtthtgRv9ClNif6lMd+hFKqk4IZQ/RhvUOKMuRfBd w4kj1uXhpHHr+fQKlget6gAUWRBjmPZbL1BiKuRO2WBd2H/1/W0AesAQlDqXE6XykEIzKGs6RIU phq26tYXz+bYQCeML1Ob36KSEkxfsJ9/sdIG72pu60FHtKKi04obrEJspMVyv/DWQRjThXkyJjU gwIh+EcDAJdPsH2+7jeQB1IqhEjz99FmOkgIyOwoR7sk1pakbSBXmZKv7eTJ05IhnaiiTmfH3T6 bK4qV0KqhXYwyI0S X-Google-Smtp-Source: AGHT+IHeLBibdH4zqSlzR+wCLp8FmVbZotd9x91bcCnPn+uZtlyga2Gxj2+rKpLxvturnXlPmT5z7w== X-Received: by 2002:a05:6512:104e:b0:546:2ff9:1542 with SMTP id 2adb3069b0e04-548510ef882mr4045558e87.53.1740567657149; Wed, 26 Feb 2025 03:00:57 -0800 (PST) Received: from localhost ([193.86.92.181]) by smtp.gmail.com with UTF8SMTPSA id a640c23a62f3a-abed20b3c01sm303064466b.167.2025.02.26.03.00.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Feb 2025 03:00:56 -0800 (PST) Date: Wed, 26 Feb 2025 12:00:55 +0100 From: Michal Hocko To: Baoquan He Cc: Gabriel Krisman Bertazi , akpm@linux-foundation.org, linux-mm@kvack.org, Mel Gorman , Vlastimil Babka Subject: Re: [PATCH] Revert "mm/page_alloc.c: don't show protection in zone's ->lowmem_reserve[] for empty zone" Message-ID: References: <20250226032258.234099-1-krisman@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 5BC5A12001B X-Stat-Signature: jsshtr1a1xbij3rmt3tqdbbkbs59om3k X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1740567659-338509 X-HE-Meta: U2FsdGVkX199VO28ST0gsepSTvEYcodPoCJ2nn5hMRr1XrAVAbqvwcE+rzBoH87e9z56em5UmrOu+cuShDDtjbuFK2M80dqsSYqtkzEtXh3Tw+qS49Jry8blAJ/I5XZsUYzw2x9hnG7yy2XUDI95QbcXWrz8JY9dFXqmhIYd6Fr2XzPP1qqpR/AmCQ+MVnyqeMGRreBh/docmTm2PC5SJPdIxiULkBXRCOkna6/WMtVsrc1FQFEyglFS9Hi4PsyB022XMCd7xJa9gb8L28468zLZR68sOf+hXUP6QtB91dMYdwVMNGmg1IiH1+v5yk4atuPq5JqKmlXDSIOsxQAuMDiyRaaaIgURZjCDwiwJOamqdup4eDPRRpYx1WVWY/MW3dBlFjbu4u+6aBeSBxNPIjhcBbqjRC7HLeahun83ZK/fNq2PIzqRRw2t+XizpHQg1cJao/b4Uewg/3e/85tmwtZwd26s/a5N7zKz3rtEr3xya/aqtS0Q7apRVij2nmsuJMknwA0DPeuXDYeBK9/3uQU2hPFbWvL7ar64mbSQrHk4kfT89uQyXiqXFMAHa+ICg0zNrNm2p0UvkWKo3wtlVLWJ82Ie2A6GgFE7S3MF5otA1SXaZoWXcO0f8WpmUWD1PDaCAh4hKYGHuuhm9X9KChv46yZqllAz8nC2QhSDLIXNXYNR7LTPkjRFfLiAXCRsnyGoMczcDlWSm8R/e25sjc3RAjS91GgBfc6KPejWLoChw0g0MLMTekWjwpeQj2OLUYLQP9oWPmtcraGCpzk2snpiArq72ztHhdYrPY06Z5i7XKFL6xHdLHPi04iUo7iOCHO19OXhS4xcaDwlTVg8tOYi+sTSDsNRBobJlR3JNZRzlqqFzAZEXbii7fQ6JvED/3FYC7tSwQNJrZSS/Zpec44WInOlIDfi9CA5chHcpv7FXU4aZ/pYo9LW728xRVz1OTifH195d/YQbK9bQ0U gwOTRd9r lSJS8xeQpAf0ylhOn/auMWJAgadh7IcHLFivF1Bezyoguzq8jDRu1RDHIWoM5y+fmY89kaAtrcv+P2XcwB7KMbcLC/P0MVN6963sHSYXrEGl5qjmiJbwO1966LLK4uyj/klurnMvdCVX4wcEBLSU6fqdmanu0M8W1L6UvNJ7ESVyODMIgtFn9xmbBmbmdkDd1xLT/D/hy6vjIUpziU3k6lFIcWwfUEJFIPz1ZgcMKSs2RtnLdXJ0cev1XHHmrOvJ17UQJfObajUIj2IgbRwC+SDlJPTVrpZWUyMZR5Tjxz8dvUVfISD8gu4INo0PLal9P2J6g1A+dmiXJ5jHLfrl+/jdc+cAmDIKFR9ekbn204zHVe8Y= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed 26-02-25 11:52:41, Michal Hocko wrote: > On Wed 26-02-25 18:00:26, Baoquan He wrote: > > On 02/26/25 at 07:54am, Michal Hocko wrote: > [...] > > > In any case 96a5c186efff seems incorrect because it assumes that the > > > protection has anything to do with how higher zone is populated while > > > the protection fundamentaly protects lower zone from higher zones > > > allocation. Those allocations are independent on the actual memory in > > > that zone. > > > > The protection value was introduced in non-NUMA time, and later adapted > > to NUMA system. While it still only reflects each zone with other zones > > within one specific node. We may need take this opportunity to > > reconsider it, e.g in the FALLBACK zonelists case it needs take crossing > > nodes into account. > > Are you suggesting zone fallback list to interleave nodes? I.e. > numa_zonelist_order we used to have in the past and that has been > removed by c9bff3eebc09 ("mm, page_alloc: rip out ZONELIST_ORDER_ZONE"). Btw. has 96a5c186efff tried to fix any actual runtime problem? The changelog doesn't say much about that. -- Michal Hocko SUSE Labs