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 E724FC021B8 for ; Wed, 26 Feb 2025 17:47:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80BD2280010; Wed, 26 Feb 2025 12:47:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B86428000A; Wed, 26 Feb 2025 12:47:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 680A9280010; Wed, 26 Feb 2025 12:47:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4B5A128000A for ; Wed, 26 Feb 2025 12:47:05 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C8CF6C0214 for ; Wed, 26 Feb 2025 17:47:04 +0000 (UTC) X-FDA: 83162826768.30.5D660BA Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by imf16.hostedemail.com (Postfix) with ESMTP id DF4B5180015 for ; Wed, 26 Feb 2025 17:47:01 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=GoXGUhPg; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.42 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=1740592022; 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=LzTIlDWrt2llrGEGz24WwEgR2IsHghqRNYfTRKzL/Cg=; b=DTVTGzQCAc/AuIwo8VK5xAPYBieRUXdY9suUSIglZMaXx8DRBbLNUga6q/CAIUAY5rPpWr 6HLd8StU7fvhD39kh7jYHrefrOpDh3/Ru9HIweMkxEEPxBfqWzbKDPl0n5dRG2LKKk0N90 6TC1QtjkjYhkYSz0G3viSkZle7Rnc2Y= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=GoXGUhPg; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.42 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=1740592022; a=rsa-sha256; cv=none; b=zU5ERkNbJzHCv8J5VwPoHPCnBa4jRdzlHzyl/5B+XuBo7uNxwRyuXTJZAkipRZ2ypMfVZu yt8k1UhqwDEhIJ9yj05UyuSIRW4EKZ74GpDdNxnLlVx6IbvWFFzfVNBVUPrVT+ByOEOnNm C4Rz6ZLLj6GLjRFzETk3PTbd3FoiXo8= Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-aaee2c5ee6eso2228666b.1 for ; Wed, 26 Feb 2025 09:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1740592020; x=1741196820; 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=LzTIlDWrt2llrGEGz24WwEgR2IsHghqRNYfTRKzL/Cg=; b=GoXGUhPg5k/0PkQIwPvl0dt02lMQLpc/zCmYvKSb8EI3ZsFsxjJQ22VVeZmqLgFTHu jh1c+7DDuklYOoYuN9jGmWKyHicHBpzApqp0ovkqMZVDsk+6fgK5it2FYJ3Jho8mUjW7 hDJkLy+QgzXz5gu8xztGbklCY8px+g5GJzyKT80d1yhq5+x4/A8ZBBLpQUw0mxpQE/us ai/wEF4Uv0HSi/BC5J7n3q7ifnV/4/g6duYtLyxFmW9uFEVFo0SYYw9+GTCsfxPtE+He zScv1qTzFpFTVPGqOz8YoEGpg/P/VZTeVT9TtZAiX5ZVa5J9nlhmhUKtvXNym1FvaJLk 0DBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740592020; x=1741196820; 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=LzTIlDWrt2llrGEGz24WwEgR2IsHghqRNYfTRKzL/Cg=; b=jo1E7QycNH+8+u3KdQybAGEnneg9yTn+9emsiN3oMAYUKSY3fcDVHgpuTowhgv1bEs 8vMU0+Wt3NTry9/zwH/BpIavnNn7XwKgkoteyhWipzhmiXoyPWpzApvutzdDCXInV11Q MWdlOUpYktkQBcZY7oSYvLrlRR7lZTaMKb9493HExRd3/X00G2oaAkopgfbQvINEWg+K ik7jdegpsEJGOtmJlL7YuiXlCOl4Kw+bB34AXZhmniLY5auAgXVf2KQKbC8QG+r+6M3w jouAphrk4QoJvVl7ho/e7vox6ft65I5qiWemGXPB8w3+ZC1VJH3DHCMvpBZe3PiHFTzm 9GLA== X-Forwarded-Encrypted: i=1; AJvYcCUpEzlsgpij4eOz1DKYBmGd6akN4ny/E/py8+3PJCKzSdEitJ/sgaBXau8AmOVICJkGNe4OZSZkdQ==@kvack.org X-Gm-Message-State: AOJu0YyFJvThDpajMCPUoPZdj1/ydn+QO1OeOPeUR+8VLEpfTsOa4863 lFk8i4NENsI5+n+yCazoveZg7r7eiNqzTQq/Y38reChDr8ZkPGOCG3IGYSSRZqd6dXfMHBLKbZ6 J X-Gm-Gg: ASbGncu/8624yjcvSWOXZW++FbIZP8S49UXJLEfYtG5TGS+Ol3hgCz+eJv6g/kCLP8c u08a7Xca/Aq/AiX7cAU+zOvNOV55EohEMpWw5laD/uRTp0G+BtqjljIBdV5vmJvXvEt3V9BZ/ax BIk5dQbIVJhoYHI/lG3hT4i+Spi7RUiCuL5vfW9Xg7qi4/gtFdbs7aKgLJj33/3EW0/MDo7OKt6 R7tc5VToYRmzaGEmTuOvgOvQq0X2kFSvpnthXqOXJcEQA0u2W0MJf1nSNNRxEhWLWxbVvH24+Q4 3NcjCzZjhKxIQVXCcdo4PdoiBx2r2dI/JoWh X-Google-Smtp-Source: AGHT+IG5TF+43+N6wCveYb1W0ZdZh1Af8fZ9cdFg50QjSBPyI5wJ9BbOLMSjCzYv0MiAENu5EqclTw== X-Received: by 2002:a17:906:9c90:b0:aa6:9624:78f7 with SMTP id a640c23a62f3a-abeeee1953emr388458266b.17.1740592019713; Wed, 26 Feb 2025 09:46:59 -0800 (PST) Received: from localhost (109-81-91-34.rct.o2.cz. [109.81.91.34]) by smtp.gmail.com with UTF8SMTPSA id a640c23a62f3a-abed20b69e3sm369750966b.179.2025.02.26.09.46.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Feb 2025 09:46:59 -0800 (PST) Date: Wed, 26 Feb 2025 18:46:58 +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-Rspam-User: X-Rspamd-Queue-Id: DF4B5180015 X-Stat-Signature: 6iosswsbcpfco7k3jsyww65n5o7qqd4a X-Rspamd-Server: rspam03 X-HE-Tag: 1740592021-303986 X-HE-Meta: U2FsdGVkX19I80Q9bGRjdjIpvm8rHjfUWQ+97/loCkfnKWivkW2FokXZ3VLXBX62NJAt/VwVg31TjWUfJTjxz//xpuzN8f/mlqS9oZ2yiJPe0lvAgFHuTbNBnE8VyaN/6pX/7hbvziXU2ZNZrnnQDB7ty8HyONg5LJbqQITybekey2gpKMflEBQSgvN1gTKcN0EI0tLZ26cb0LzlXMcrIclh2qSvWj1TTuqEmmCpsiHOGaKAlVBNxL9yXNFaPRXiLjgaz+kN5iEpH9TblAD2QbwNA3mBcWHMOpI8Yb6GFMi2mPYC893+bPRV5yIDK8CsWDd2GhkiC3ZhOi5naiazydzInpV/rqqfR6Op55Mrx1dWvAbEddCdbRaxjHSx+2dEv5T4dZ+Ce+PA8EhRqpJGQtMGTsxC1AKDKTEjAQiRiphJoBWVA6I7q7Pz4DcyhXEeY1TMhigZJVzK7iGHGRbWxmL0qlfnkrLR8eP7IkVK7Q9UQvk81SqY8fnyqDGSFOIBPtGWJFzdAaMfF896PAPho8pHn4YdEnUns07cyUgrVdPNXPLjTM1It9eLKwz1jDLRnTfQ+ciEkdLFWJUWg/aRtA5yhUmOFd0sMgZNrTV22UmcCStXITLad9cs4EgZuRpWgRE1CiThpbgaPbXuCc8B/E5kFIqEzvNNbhP9w3CTtPlusHfBuhKVKY8CjixAPgOFiBnsycjbQ6pdgNGVpv0EAoYPzonUc7269VhKPw9reEW6Ei2cUkp9wnc28TIowM4idPAWGivaTbmzCH5cNPZX7AjpBO/XqOPgKSv5dvr+lKw+J5miNvCBZjd/YN9OG1+3DsUNTDsowFSN4gIy04HXgWdwkshykE9SQyJ8zJDdTe6t8fP0/QV3pkPsj4qpQzRS1Vt+osPi7o+kWG54TormoQfVU6AeKeUsPhUSoUYqW02FVorkWBBZAvRLxhh+tC9iLhozR2kucpMQJsmkh3k vpVQ3XLj kzb6eaoZ4qzttOKz8e7SsTN9vIo3CKmNOzP93liS3ZNtY1+zvjuJgDcDlIXfawVPd4TR35YM5IU9xOX4X585CMWabHPWg9ZjZ9gjWENh9UhoDxigBDRU6mo8K+ajTB8V8yP3gHG2jLcHr6tqzbe6XEHOs3ibykYhircXnpM8/mYjadsfggMio1nnlyAgMhSBeLn6TqDGmUI8Kzad8eu6KY0vZ0NpJQZWOLnKskA/f6d2Ls7JzSvQ+2TyXKcNRdhpwh7TXutPCj1886TIBsw9T+qzzR+ZNjpfh8zzNwNdCs/lJKhTorwN64GGLbBumEf6dTfVXgssMq/5JZ7kGzNGhBOgldVQOwaL8kD2a4wnJQ+Z7h+4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000024, 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 23:57:48, Baoquan He wrote: > On 02/26/25 at 01:01pm, Michal Hocko wrote: > > On Wed 26-02-25 19:51:12, Baoquan He wrote: > > > On 02/26/25 at 12:00pm, Michal Hocko wrote: > > > > 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"). > > > > > > Hmm, if Gabriel can provide detailed node/zone information of the > > > system, we can check if there's anything we can do to adjust > > > zone->lowmem_reserve[] to reflect its real usage and semantics. > > > > Why do you think anything needs to be adjusted? > > No, I don't think like that. But I am wondering what makes you get > the conclusion. > > > > > > I haven't thought of the whole zone fallback list to interleave nodes > > > which invovles a lot of change. > > > > > > > > > > > Btw. has 96a5c186efff tried to fix any actual runtime problem? The > > > > changelog doesn't say much about that. > > > > > > No, no actual problem was observed on tht. > > > > OK > > > > > I was just trying to make > > > clear the semantics because I was confused by its obscure value printing > > > of zone->lowmem_reserve[] in /proc/zoneinfo. > > > > > > I think we can merge this reverting firstly, then to investigate how to > > > better clarify it. > > > > What do you think needs to be clarify? How exactly is the original > > output confusing? > > When I did the change, I wrote the reason in commit log. I don't think > you care to read it from your talking. Let me explain again, in > setup_per_zone_lowmem_reserve(), each zone's protection value is > calculated based on its own node's zones. E.g below on node 0, its > Movable zone and Device zone are empty but still show influence on > Normal/DMA32/DMA zone, this is unreasonable from the protection value > calculating code and its showing. You said that in the commit message without explanation why. Also I claim this is just wrong because the zone's protection is independent on the size of the zone that it is protected from. I have explained why I believe but let me reiterate. ZONE_DMA32 should be protected from GFP_MOVABLE even if the zone movable is empty (same as if it had a single or many pages). Why? Because, the lowmem reserve protects low memory allocation requests. See my point? Is that reasoning clear? P.S. I think we can have a more productive discussion without accusations. -- Michal Hocko SUSE Labs