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 B75B1C19F32 for ; Thu, 27 Feb 2025 15:53:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29E2A6B0085; Thu, 27 Feb 2025 10:53:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 24E896B0088; Thu, 27 Feb 2025 10:53:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 115FB6B0089; Thu, 27 Feb 2025 10:53:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E9D8C6B0085 for ; Thu, 27 Feb 2025 10:53:58 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id AB7A11C8B2A for ; Thu, 27 Feb 2025 15:53:58 +0000 (UTC) X-FDA: 83166170556.19.3B21F2C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf20.hostedemail.com (Postfix) with ESMTP id AAB121C001B for ; Thu, 27 Feb 2025 15:53:56 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=I902op+N; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf20.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740671636; a=rsa-sha256; cv=none; b=eE5NgNINZ1Nr22VvFJ0JhEbt+YWhHv8fWqCHtHIUOhJQRUaWlIFRlq4Z/MGehmLOUX7vPq ZIH8k3gA0YrowDmSkB50M7/Y2wo8Lm7lW8VRSP+HcosFMu0vfRHKn269HrpB/1nzZsKiXW jYophLRw2GaeqMLuulRpOXHMEpkU10M= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=I902op+N; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf20.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740671636; 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=iGUM8xICJBP6IHluuf5oTE9etnydVkjIpWH/zF8bU5Y=; b=dfRx/mcBTfbycrJ6sUdnvpvYLkOf5xfXCR9Gzeww3cIvuGaT1IjfHK6ixM4bK49II4gLQi U7THBPLj7h/elc1Uo7tayqG6rQUV/a6lEClt9MtFkbzYPplyl1k4PPf6ZlS21QDdRBZ010 4UB5Nty+hY+Tt/qq1rx4/zRo1u35CP4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1740671636; 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=iGUM8xICJBP6IHluuf5oTE9etnydVkjIpWH/zF8bU5Y=; b=I902op+NC4B7GDEzJktqRbjmeJI2p34Zax+49WEYeX3r+WldVdsndZUhho6vAIgO3tFgpH /+xlxq+rEDHzhBQnFGrXvbmdMMsm/Qh0CF+tb+7/tq/8Xa36Eam+6QllONbXLlPSIpg2bs lDFBfAJ0sl1TeP0Ct74R3xF4CbPrmRg= Received: from mx-prod-mc-06.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-365-tK6QzFG1O8aHEBIwhYqQow-1; Thu, 27 Feb 2025 10:53:51 -0500 X-MC-Unique: tK6QzFG1O8aHEBIwhYqQow-1 X-Mimecast-MFC-AGG-ID: tK6QzFG1O8aHEBIwhYqQow_1740671628 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 93204180034A; Thu, 27 Feb 2025 15:53:47 +0000 (UTC) Received: from localhost (unknown [10.72.112.52]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 43A3719560AE; Thu, 27 Feb 2025 15:53:45 +0000 (UTC) Date: Thu, 27 Feb 2025 23:53:41 +0800 From: Baoquan He To: Vlastimil Babka Cc: Michal Hocko , Gabriel Krisman Bertazi , akpm@linux-foundation.org, linux-mm@kvack.org, Mel Gorman , Petr Tesarik Subject: Re: [PATCH] Revert "mm/page_alloc.c: don't show protection in zone's ->lowmem_reserve[] for empty zone" Message-ID: References: <2ca6130a-3756-4480-8453-77c702d919da@suse.cz> MIME-Version: 1.0 In-Reply-To: <2ca6130a-3756-4480-8453-77c702d919da@suse.cz> X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: _xK138uuSQ6Qg5TTBJi0yrDhPDEMIqlaHt6aE2YlLso_1740671628 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: AAB121C001B X-Stat-Signature: a8rb36j1msar3bx4xwcijusmzdxarexm X-Rspam-User: X-HE-Tag: 1740671636-961739 X-HE-Meta: U2FsdGVkX1+U4526yvdI4R0HMLw0ymqn/tu3h0x+rpb4UedVUIjHU15GCOQweFfk1jyAlBauQdyg3dmbdxcK/z9GQ6m1LBmmGXUpfnYOywwQh1hDsDy6Bb+80IhVlKbnccpAxcC1Q4Cpn4rdQKvpGbMoEPwniLBY61pIonyABA39DcitZmfi+Tx/Gx10sI2qUoWBh5iETVCYrP9Do7Dkj2b7ivCwNB8q7zGsc26XJIbZLdshmjwMj7pz+xPse6QlhUj4y+LwH5QOYftaopwk847RrAD7d9VxKCVjG3uiWErQGScxng6aLMqxALM1VLy+n40NllCLPRnJo//lXDVgfypUL0f0XoSooEqmFjH08BaFpAUF6HC6B8jNeQhOy9HHKnTQEHjEZm+cgF0zsnMB+C2t9HPfM6ghaX9hWpACFRoOyTEeb8nBLJ+N+XJuVT0R/lZoY/CneE9NiJtL6JGvfl6C9jJzWXtbfc6xblXZ4CjhVabwk4IJaEniMZyX0o7tq7pWhXeicT894zM+8wcaofV8wO8yYhZshcuJ92zHHlJVtp8FEePWCPtX6DcRd+Y2j7QIo5ajh2w3nmRD62MTRCwDtE8jiEfDzuWB0iInXwH8xzbNYP0UKvG1ZaWgdPM5xW+hCwsuB7s5NyaQ5WwNDVOXAQ/BgBalnueIZKQKIkTYS7v+vWKYJTHzQ+jXNKpb5r3ncBc3uUcdhY8Ih7FQRFndVd9NdGe3s47aRcI+u/BR36kQoN7b4yRfYNUDiHbOoSvghenmW5bC4C7nAP6C/5lbxzz67wMfSLIAqY7NjShQu1j3QLl6fM1ySBOwyGH4/1iQ9qJp4dFCyMTpuanapl8OuNZlA7y8JqUilgKDo+RNscrqaq5yknckQKfCC1vgek9cU448OgCQjgAdk+Ai7lbvwxdfXG6MIZgkxjifbUqcg9r8GTVCv2ixyHRhUWGIPQlO7UW/PpRrCsL4rHL OXy1AZ+e dyKt9e8WoBLKtqokadZOEVI/m3f1vhxeDBVkKeq5S6R/+bAf09mldTirNj68AuM33JweM86nA18SUFAUwrddgbFW2f4mbvoj9S/kF7yUomxsoUIZFUBTIfQOwC1jaAzTRpjycA/epvUMp1FEyaxApM1PYyZFlKMRn8gboZfRDkH4Ykjz5imiAurSeGPTTQ4tAefvrkLlwHQ3u3ve+1eUQnvIGaTZfRvIxEathrdxu9dg1FRM7VHn8u4R3Rk9YdineJYVVfrHeCDLnmM2E0Fn8GOyA0hxdlS6gSyDfE+SNp3M+Bf6WZMtT364yGROkJDNES8EWZ0UjwdDvwRmzJ3W19mreiHjLssm3DuWSDNGzqoSCbzMfxV0oPeF/OVk6OoWJw4sLCAj/AMs0DNPMtDneOihl1VuP78Bzif7tKYrpPF1rIFiGBBws1CMwwRvwIvGfEyR2AF4kM00n8o/NANjo2o9VFTyh/yWAN32gHzXddSDR7NI= 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/27/25 at 02:16pm, Vlastimil Babka wrote: > On 2/27/25 11:24, Baoquan He wrote: > >> I guess the issue doesn't happen in practice. In any case it's out of scope > >> of the reverted commit and the revert. > > It could happen on arm64 because arm64 only has ZONE_DMA by default and > > its boundary is not fixed. I saw all zones are ZONE_DMA on arm64, I > > guess it could be easier to see a arm64 system which only has ZONE_DMA > > on node 0 and ZONE_NORMAL/MOVABLE on other nodes. > > Does it mean the ZONE_DMA is rather large then on arm64 then? In that case Hmm, means it's more likely happening on arm64 that there's only ZONE_DMA on node0 because its node/zone layout could more flexibly customized in firmware by ystem vendor, but not like x86_64 with fixed range of ZONE_DMA, ZONE_DMA32 and there's always ZONE_NORMAL in node0. > things probably works fine even if no protection is applied to it. The x86 > ones are small and thus need(ed) it much more. So I don't think we > proactively need to change anything unless there are known issues observed > in practice. I am fine if we decide to leave it since we have made clear the root cause and all the potential issues. Once known issue reported, we can do the change at that time. > > Another reason to avoid the effort is that hopefully we'll get rid of the > DMA zones anyway? They don't work all that well anyway in modern times. > Ccing Petr for awareness (due to his recent LPC talk about this topic) Thanks for telling. I noticed Petr's interesting presentation in LPC 2024, that sounds very stunning but very attractive if it's finally achieved. But I love it. I think that's a good one to vote for not touching the proctection value for now.