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 0B67CC83F1A for ; Sun, 20 Jul 2025 12:38:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4BC2A6B009C; Sun, 20 Jul 2025 08:38:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 46CB76B009D; Sun, 20 Jul 2025 08:38:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3828E6B009E; Sun, 20 Jul 2025 08:38:28 -0400 (EDT) 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 23F316B009C for ; Sun, 20 Jul 2025 08:38:28 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BC04011163A for ; Sun, 20 Jul 2025 12:38:27 +0000 (UTC) X-FDA: 83684596254.02.AEC8AC4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 0357514000A for ; Sun, 20 Jul 2025 12:38:25 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=DQU3ljgC; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1753015106; a=rsa-sha256; cv=none; b=TbMe5oXXHfD0j4L6OM+MbAf14yrtKuDolJ4At3irgslLUb4TJUZn6h6YsgteT5tUA3ArSW f7Rw0m5TeqoF4vYHAYz4VvHi2Yjvur7UJFgMkmHh3euytKZpT/nnxZZRzY2odI7gpmk/yL 6jFCf0oT2Co0p96i6Nhm5tk7eNHbp8A= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=DQU3ljgC; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1753015106; 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=Wwm7/Yhq0PMCFdWk1ptbBuP1xxAbAqcyy+YG9CHbpi4=; b=hlbyiFceWRacg+HPA8eqoWdIWI0u7/DiFVos/8wivxcQ79plnh9v/xDuv98btDEmHUZ2cn 1kF2bUGWekBlZOC3CVIZZ6BlPUwxloXci63SZRCEr280M0j/Q6jSyskvCzYryZGf3NrXKj vUVtjN4n368U3+f03/NfBD438U5om+E= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 20C385C4239; Sun, 20 Jul 2025 12:38:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8803C4CEE7; Sun, 20 Jul 2025 12:38:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1753015104; bh=3U0HLcGYrlk1llQSOsm7NoFj2/bLDVh50DsU8t7Su/c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DQU3ljgCYyucZM+zhIVqhpvT+Y2gyGRqJ54n//8D2Zn1PHqyWSYp+onysy9VM7oDP TAHiIq+pAA7YQaTfOlUz51wk3/l7A4DLo4dBqDjEfcpJKGIXN0AswafihFafjSyiL7 2sJiFjbpYdjoDsZgGPaq9o0oxvZVde9AICvRvZ4VZ4PHVJ/GVD6kKXzoFJcmTp9njQ 6t2VLaYjPgBG5vQrQaAtQBx29v8QRxXmeFgWzxQqf+6uubZwAYumuZ2N81DiZjUF/9 N5RY+WUQsn//PfyqmenApQmcl1bo3SEGzIlNNeExO12BRGwk4KuDpbJ5uPRGAOkoL3 wIIbCFLBBl5RQ== Date: Sun, 20 Jul 2025 15:38:19 +0300 From: Mike Rapoport To: mawupeng Cc: akpm@linux-foundation.org, ardb@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: ignore nomap memory during mirror init Message-ID: References: <20250717085723.1875462-1-mawupeng1@huawei.com> <9688e968-e9af-4143-b550-16c02a0b4ceb@huawei.com> <8d604308-36d3-4b55-8ddb-b33f8b586c1a@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8d604308-36d3-4b55-8ddb-b33f8b586c1a@huawei.com> X-Stat-Signature: iyyudsemdo1sji1f575o7bczzcwc7drg X-Rspam-User: X-Rspamd-Queue-Id: 0357514000A X-Rspamd-Server: rspam02 X-HE-Tag: 1753015105-725928 X-HE-Meta: U2FsdGVkX195o0owW82D1hBaf+heDXA4pYaaZZarxiMnKouv/GGYG2Bu+t2x+d8OaCP5Flz0wYsjgpGdDOFK0Co4DbsRhAE/PVfknz7m3V64kg4+96cRwBho3jYEWtzpM4VKGG0CjhMCWU3hNsnXDI8WXF+oiCEGOSSR/fHhVnDATA0a+1IRXqKPNaUB7xDMOeMGak95JIt0HEwl/R8zopkp+2axEG7oDY4rFQ+jNlGhcb4K2ehR4oyyKrD1icVO2oFlCRIsHiMeZwhc5Z3u+8wSu9IEIhrLTnBvSIPuNrd66D+Gb5itu62zX1Z4E7zFz87lx0XmvU1EzJdjUB3vMor8QadNt3tMKByK8DKMyC/fLr1jQuFRym2MUO+SYi+exbmWkwyPpltchwwBRJjWsIqwyMgnLNErPvTd1C0s7jBLYYUAsZuEhZMqCxvPaLMiMi5yutVQIDm+3YweRsiqfxfXfTxj4R0RcyNAVdKcTppiHJ7gl42xK+CTrGeyoOEqhSiLzyd9BAzDx2HHDgNb68PZtsk8Vxn45QYI6qj2CnSWiT6Y4ols74MyP79ROLlVMJTsnbr5BkCqPFHtz4n5dZv/xRBS7JSfvf6QkD54/9Kq0yy5XwA/kPshAMzvyIP1VLRbJwJoRVVC0Wt2zSAhOFiqIGfGt/Rn9TfvQw91jo7B3bVR+VErD8xLXgrG/lKvIhf/rISuNBPAznPjo+VuVlI+9K/BxB9E8qczbmtw1J5OueHUVPdTmRLkKFrH9AWTChe9a9bni1TbYvv6D+KdX9VM65EyFBIsilnao1edHXgkTI8Flbor7LEgoJ77eT2deVUB6fRbgUN3wzH4c3IQr3muG4Wqoar1+sw9EwKVB8qyCOE0N1oOkpJYLIi4KyVihKxra+Ad+oQ8Dz1tv00NlqP3Ui7hT0/OCAnLB4pjTb8/aN3cKF3rFxT82sy70L63ADlOv7p3u5yRHeOU2V2 iESdhKW/ A3p/RUbV10pvdyFNqZ9QJt0a1M3zM42J0mmV5eCirmRvbSaCw7JfYnzhdnTglXjRSaYCkKN5clGI66wP9q7QNyczopMAbqkyZ55+kcSBRXH5yUxY1HAepQlam0T/rd0xbgK7CNIiIF6X/nINwjrVOHKEGqkQje4qCB/Yy7o27qeo1KekaidbMRcNUVkBuZKshZaCLyghSPEh51+yvsvZXzyzr+IFkHfDO/PMwbeVVQgDkOu/6SlxEp0SHqEyNd+4zau7v 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 Fri, Jul 18, 2025 at 09:37:48AM +0800, mawupeng wrote: > > > On 2025/7/17 21:37, Mike Rapoport wrote: > > On Thu, Jul 17, 2025 at 07:06:52PM +0800, mawupeng wrote: > >> > >> On 2025/7/17 18:29, Mike Rapoport wrote: > >>> On Thu, Jul 17, 2025 at 04:57:23PM +0800, Wupeng Ma wrote: > >>>> When memory mirroring is enabled, the BIOS may reserve memory regions > >>>> at the start of the physical address space without the MR flag. This will > >>>> lead to zone_movable_pfn to be updated to the start of these reserved > >>>> regions, resulting in subsequent mirrored memory being ignored. > >>>> > >>>> Here is the log with efi=debug enabled: > >>>> efi: 0x084004000000-0x0842bf37ffff [Conventional| | |MR|...|WB|WT|WC| ] > >>>> efi: 0x0842bf380000-0x0842c21effff [Loader Code | | |MR|...|WB|WT|WC| ] > >>>> efi: 0x0842c21f0000-0x0847ffffffff [Conventional| | |MR|...|WB|WT|WC| ] > >>>> efi: 0x085000000000-0x085fffffffff [Conventional| | | |...|WB|WT|WC| ] > >>>> ... > >>>> efi: 0x084000000000-0x084003ffffff [Reserved | | | |...|WB|WT|WC| ] > >>>> > >>>> Since this kind of memory can not be used by kernel. ignore nomap memory to fix > >>>> this issue. > >> > >> Since the first non-mirror pfn of this node is 0x084000000000, then zone_movable_pfn > >> for this node will be updated to this. This will lead to Mirror Region > >> - 0x084004000000-0x0842bf37ffff > >> - 0x0842bf380000-0x0842c21effff > >> - 0x0842c21f0000-0x0847ffffffff > >> be seen as non-mirror memory since zone_movable_pfn will be the start_pfn of this node > >> in adjust_zone_range_for_zone_movable(). > > > > What do you mean by "seen as non-mirror memory"? > > It mean these memory range will be add to movable zone. > > > > > What is the problem with having movable zone on that node start at > > 0x084000000000? > > > > Can you post the kernel log up to "Memory: nK/mK available" line for more > > context? > > Memory: nK/mK available can not see be problem here, since there is nothing wrong > with the total memory. However this problem can be shown via lsmem --output-all I didn't ask for that particular line but for *up to that line*. > w/o this patch > [root@localhost ~]# lsmem --output-all > RANGE SIZE STATE REMOVABLE BLOCK NODE ZONES > 0x0000084000000000-0x00000847ffffffff 32G online yes 67584-67839 0 Movable > 0x0000085000000000-0x0000085fffffffff 64G online yes 68096-68607 0 Movable > > w/ this patch > [root@localhost ~]# lsmem --output-all > RANGE SIZE STATE REMOVABLE BLOCK NODE ZONES > 0x0000084000000000-0x00000847ffffffff 32G online yes 8448-8479 0 Normal > 0x0000085000000000-0x0000085fffffffff 64G online yes 8512-8575 0 Movable As I see the problem, you have a problematic firmware that fails to report memory as mirrored because it reserved for firmware own use. This causes for non-mirrored memory to appear before mirrored memory. And this breaks an assumption in find_zone_movable_pfns_for_nodes() that mirrored memory always has lower addresses than non-mirrored memory and you end up wiht having all the memory in movable zone. So to workaround this firmware issue you propose a hack that would skip NOMAP regions while calculating zone_movable_pfn because your particular firmware reports the reserved mirrored memory as NOMAP. Why don't you simply pass "kernelcore=32G" on the command line and you'll get the same result. > As shown above, All memory in this node is added to Zone Movable even some range of the memory > is mirror memory. With this patch, 0x0000084000000000-0x00000847ffffffff will be added to > zone normal as expected since the MR attribute. -- Sincerely yours, Mike.