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 76D8DC83F22 for ; Mon, 21 Jul 2025 02:11:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 949A38E0002; Sun, 20 Jul 2025 22:11:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F9498E0001; Sun, 20 Jul 2025 22:11:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8363C8E0002; Sun, 20 Jul 2025 22:11:22 -0400 (EDT) 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 7152F8E0001 for ; Sun, 20 Jul 2025 22:11:22 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id AA3FFC0581 for ; Mon, 21 Jul 2025 02:11:21 +0000 (UTC) X-FDA: 83686644762.16.3D73AE3 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf02.hostedemail.com (Postfix) with ESMTP id 68B1780007 for ; Mon, 21 Jul 2025 02:11:17 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf02.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=mawupeng1@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1753063878; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XmGV4bBqyl2ssjS42ICBr2nwGWoSaJU6u+d/74L/gag=; b=URslqx9blFN731j5TP9wgmMEQ4QrTaI0oIpqBhxKB3vQ6Hr2/lYqKIphC5Z/GCGTGBrzyX Sak/AJRPgKidWluYFmBMaD/xqOTvWwSOpYXmehM+YP6Mp5cRfkk16Tk8+3Atl78LK2rUXU PwiL26Xo89Z9JrknxD9IZdQOfUgV1j0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1753063878; a=rsa-sha256; cv=none; b=4ufnjx069FA3YH5LePivoBSCfwK1HwPFiEMiRbqV7n5NyH/+yLneywjjSNdelTG22Jx20I KI1js5+sd4Iu2Mr3DC4QwSwsw4bAQVjJS62X/hcUkKPvl865erbAp6nxpBTnfzk5z1Ri4A EVFX9j/Lm0sZ1Dut1IBq42EB08C5L9E= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf02.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=mawupeng1@huawei.com Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4blkMh5hXQz2gKkV; Mon, 21 Jul 2025 10:08:32 +0800 (CST) Received: from kwepemg100017.china.huawei.com (unknown [7.202.181.58]) by mail.maildlp.com (Postfix) with ESMTPS id 3EDFB1401F2; Mon, 21 Jul 2025 10:11:12 +0800 (CST) Received: from [10.174.178.114] (10.174.178.114) by kwepemg100017.china.huawei.com (7.202.181.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 21 Jul 2025 10:11:11 +0800 Message-ID: <205873c9-b8cd-4aa7-822e-3c1d6a5a5ea7@huawei.com> Date: Mon, 21 Jul 2025 10:11:11 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird CC: , , , , Subject: Re: [PATCH] mm: ignore nomap memory during mirror init To: References: <20250717085723.1875462-1-mawupeng1@huawei.com> <9688e968-e9af-4143-b550-16c02a0b4ceb@huawei.com> <8d604308-36d3-4b55-8ddb-b33f8b586c1a@huawei.com> From: mawupeng In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.114] X-ClientProxiedBy: kwepems100001.china.huawei.com (7.221.188.238) To kwepemg100017.china.huawei.com (7.202.181.58) X-Rspamd-Queue-Id: 68B1780007 X-Rspam-User: X-Rspamd-Server: rspam09 X-Stat-Signature: rhfb9m4k8ge3addstbdnyn7qrn63dgya X-HE-Tag: 1753063877-741427 X-HE-Meta: U2FsdGVkX19fBSbgNrfFkq8DaLamL4GMhV0TkfFF2NavqRH9ML3NWQKCiSPMSvhQH57GULicVJ/fSQAR1mVZ+pJEzes9UtfxkOztlVePTpoB1B6cHqD1ZwRyT//HE6E/73/p25pjLcVGaccGQzpq3MGbt6n0QHoUOSca2yNoXR3FTDxiafqC8//tm7IgM5lSI/NvZF3SVdtAGYDIaLoLJgg5XfNoOWvwb4s7oEbkrx8ZSYv7yjuFUBM++L75zIQ86FxSzgceAf6Y6Tr1OSe1m3ETqb740D4vSkC8q3/JwGAfy3f0773cCQ/uRwrQNJBn+5DgCaG+QCAXRzA/9cgVZhQz1BXvkR6PpoCFiSnEaINuepiYe/GEfQmEAWhy90diqOpVQj2UcLd3cYfzvq6QmJal7x5n2YUcHZFp+ZAsETkaTr7VUf4hV0TfrqRQd39WXqkTOh+aa/JShrgRpPl01tH9GirXms80UHTFJFxVG0KW3BMBjlb2QmCPSDbN9pDIxfHFLkNijJyCtbTSOkkZCwVYS8kbe/VpErp/g+ufA84XBjqO5DP2+QhTQZOvutg9LZxatgCWym+isRNUQgdvc4XrEUMvZV/fe1W8aCyDPpIZEY2wOu3ZGiKUP3R2om1eBacMQroCW0RupKH7nYDkbwoWWtz2M6yw1KK+YbZniRe0ov7hSZQKOgAmSOvadbPmvad14OoW2s7OhPSmN+S3aHlTk+zC5ujztCNrMKBnzi9NU+ZEZCpfvQVp2XH9Wg7xL+UEVHSp3DXoV8I2Z7bT786IVB6ecClbAz/d0Bzd97COu3nDeo+cG4MWuPZjbGT0mSJ0bQUT4iFSagA8B0FmAMwoUD+M7RMC3kQunjbwYQih/t98FYFIgIeKqirji8mGOET/7kg8tAwQsKb5Mer7xd+XBs8HZTwmwBcgDw+MBhrboybeO92Vpg1N9YHAUpVmZXFYl7T3brxocPt7axL kMBECcz2 1oQ9O9aWUV3F2b2P/drCdEw2gs6mysn0fLcZyvsEjeSC/mZnGz1u1X0HCnJRRvR3OwyJXzvNC8NV4JpsqNKRtKOD4idwCVD0orzb2bmJG+WOEd6q9hEYa5NeQ95IB3WhuyyN8ZnW3dWfgD5nFWkrcNSWUQBVFMBlpoW0KBcS+jf/Eo860n2aOnv+x5s8lcNu1S7Vn8eN10FtKk0WvIuhjOBdHeg== 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 2025/7/20 20:38, Mike Rapoport wrote: > 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. Yes. > > 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. Since mirrored memory are in each node, not only one, "kernelcore=32G" can not fix this problem. Since nomap memory can not be used by kernel anyway. AFICT ignore this during mirror memory init is the right thing to do. > >> 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. >