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 AA4DFC021B8 for ; Wed, 26 Feb 2025 15:58:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 408CD28000F; Wed, 26 Feb 2025 10:58:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B90B280001; Wed, 26 Feb 2025 10:58:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 280C028000F; Wed, 26 Feb 2025 10:58:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 07025280001 for ; Wed, 26 Feb 2025 10:58:06 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A945653556 for ; Wed, 26 Feb 2025 15:58:05 +0000 (UTC) X-FDA: 83162552130.26.8620045 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 ACD6BA0006 for ; Wed, 26 Feb 2025 15:58:03 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=E5pwtMoU; spf=pass (imf15.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740585483; 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=pdBhpldaOczXUTM+hMCp8TzqtcHI+a+PM01T4Babmv8=; b=gaZ+yb45grg3x/+pEp5J3Yl5EfgiFyGi0EtkCMQxz3EY8F6YE1CewJ4VLHIMpHuiBEaMtX 7B9RuAgYX+36vMl2yIO6fRLX3D/EAlbNxU7sts6uNpB7wB5Wx5uwrEc5INXyFRhDSa6Gp/ rjfTZwoPjtlDhGspeyZJIzh36/A6y6M= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=E5pwtMoU; spf=pass (imf15.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740585483; a=rsa-sha256; cv=none; b=Gk/fjWbfDA0KcntJYrHnawX8o4Q43Dznkpouyjj9DOyQsbeidpq+c7etBDc8YCZWFw1xVF G6pbH6bBU7Xfo6L2xLXlycgQlFEGu+D8ZQJ/cLHy3cEYtcnLr5iUKT1PIuyB6qNPTBDEhb ZhvqQGZsU02jyPpiGey09ulZfxaHmhc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1740585482; 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: in-reply-to:in-reply-to:references:references; bh=pdBhpldaOczXUTM+hMCp8TzqtcHI+a+PM01T4Babmv8=; b=E5pwtMoUWy5jI5QJfU1+aF7f+117P4WItcU/GZcxP3nR3XkzuI73JAGOyCoN6gENHMQleI I4gi7OwtsJOsqEqGh8PWLFMAm6A0ZIamdxwgewMhP7AArHW0qRJjLtjSpVNwE0IpRNZc5p V+A8jInhBo2IHLXFj4pTFzlFFhLlyuM= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-500-HOc0N6gBN7qZfWqdQsqMWg-1; Wed, 26 Feb 2025 10:57:55 -0500 X-MC-Unique: HOc0N6gBN7qZfWqdQsqMWg-1 X-Mimecast-MFC-AGG-ID: HOc0N6gBN7qZfWqdQsqMWg_1740585474 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6E56B1800373; Wed, 26 Feb 2025 15:57:54 +0000 (UTC) Received: from localhost (unknown [10.72.112.31]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 1C494180087F; Wed, 26 Feb 2025 15:57:52 +0000 (UTC) Date: Wed, 26 Feb 2025 23:57:48 +0800 From: Baoquan He To: Michal Hocko 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 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: eOyaa3yr0V1mUDyQiF3C3JQDPvD8oWuog0vd_nPKMHw_1740585474 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: ACD6BA0006 X-Stat-Signature: 3615fdy3tua7cuatcg6h45xputxtt8xk X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1740585483-976453 X-HE-Meta: U2FsdGVkX19wWHJqzGZL3BdQBzHtlJNKFI3v9YC3wXyQ3oUtn6//lNXc8UCypZtD2+IXZ4rqwWSxo1uzEJFLeDiWv0Nme4GP1oH0LNOiSQh0nR83v+J3g5Sc1C+OqGbkT1x0W1mDnb/S8yJKIbygBU+/ZEv5bjT2ZeBT//dyUd83WqdySIoTD8X4+QWrHTEx3csFfNa6SIA/DYvL2FNa3yOHwwTD/rUE1NgDY+SMhx8CvfPi2gkWfZXStJzEzK0I+ITC5TVeWDxhD6K8KMilJ3+PHWkJBDrSSxxUUZ8YHmlfHGRDDFhqVmyJ7P+dtVRlpTPONuSjOhvXLREHodlWHAMVlF+n/yVeITOWXMT0n+45cyyHr14W8xj4cMW8+honvsyj23rSPpLsKZNVtNm36f8RYJYfUp+PAI+wzCHbw1MgIDQ77vB9Rdd3NTkyax5YkRcdvBeYxYdRa7lnMyDrdgVLejo2JUwTQBhzydrW/bG71IFmGg8V4cqxmHr7brqRcpXBuLQQKIMnf+GADq89XQnoXiPgKINnQdDmIBxgjheigbme3FZGgB/1mnDG1jwo8Zyb7MT0evxtaSen0aU2vp4WKLTbjDIAt+dwQnbEfXMmVp2D6NxZAb4fDBEUxQYsgSHseciHmirrAZA7K+VXmAhMJqoJCluF5KPjYs36LHyym+yvFfe2KJGkhiKp62eOs9PqTPswO25jKcQ4l2OhIPci5YO5MILjsFoWGyQbyA+Np+6sHERrK0D7sjsivSUF+omV5H6wLXOciFGCsIFOF/7Y5JkQYw+iDRYxWS2QT9nINlQaC3Nm9gGLX7DxZpg43nupVkT+uTAMqpPJZeLnsrqMY1nFpEbkSp8UZ245b4AP5pPcoIKD3hncWPXYDnG/cv5ONph0MWyeuSgLZedOFQORBF08ii60LId8IoED2IVMvUZbiq7Ir7t/JIWF/rMsfj07bQWtDKg7qwv3wGm +nZPyuPj xOQsfRstW6AnEpxTycRI3z2/LuqNJSD4x58JPND1YdzsQCYrn28F/zxBOcF9a752uFfnf+kthkxS4ud/0eOdSsih68kw6oXgLpFhlkrvSAJ2+plhz5UzNf1u6nXVTkmmVFhSp54o8NMlpxKEqVmo/j5d7m/DPBlH+k/kP6G3B4nAPVrPr4teO265sKA+/erVQvswwCvCarBQHfOGLOsoG7IBA8p7RwCk3zcGhKI/csO6ublq1r9MFvsBeIqs9azWIy6DfZL+PKmN3/fXa7j1W9AouPxtMyW7Kq/7yScDRyAPRxoPbwzVIeMuMIgFSV+wVi4xfMp70/S7STRGoufTwLFBDdknbJsansbVSVK32UyETc+x7KnPd/QzotMdyJTJeUDWnE50v6W27JK+In6EYIoBJ+c44PDPzcs2NCD3i1niU0hWU73uDOg6sQdKWxpyansPiTUtxfzJOZFDsmuz+s+lhc/s2jlGuU/dl4T1SGxgVdtc= 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: List-Subscribe: List-Unsubscribe: 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. If really as your colleague Gabriel said, the protection value of DMA zone on node 0 will impact allocation when targeted zone is Movable zone, we may need consider the protection value calcuation acorss nodes. Because the impact happens among different nodes. I only said we can do investigation, I didn't said we need change or have to change. Node 0, zone DMA ...... pages free 2816 ...... protection: (0, 1582, 23716, 23716, 23716) Node 0, zone DMA32 pages free 403269 ...... protection: (0, 0, 22134, 22134, 22134) Node 0, zone Normal pages free 5423879 ...... protection: (0, 0, 0, 0, 0) Node 0, zone Movable pages free 0 ...... protection: (0, 0, 0, 0, 0) Node 0, zone Device pages free 0 ...... protection: (0, 0, 0, 0, 0) > > -- > Michal Hocko > SUSE Labs >