[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SA1PR12MB7199585DDC589EEFC23FCF4EB0F1A@SA1PR12MB7199.namprd12.prod.outlook.com>
Date: Fri, 24 Oct 2025 11:26:19 +0000
From: Ankit Agrawal <ankita@...dia.com>
To: Shuai Xue <xueshuai@...ux.alibaba.com>, Ira Weiny <ira.weiny@...el.com>,
"Luck, Tony" <tony.luck@...el.com>, Aniket Agashe <aniketa@...dia.com>,
Vikram Sethi <vsethi@...dia.com>, Jason Gunthorpe <jgg@...dia.com>, Matt Ochs
<mochs@...dia.com>, Shameer Kolothum <skolothumtho@...dia.com>,
"linmiaohe@...wei.com" <linmiaohe@...wei.com>, "nao.horiguchi@...il.com"
<nao.horiguchi@...il.com>, "akpm@...ux-foundation.org"
<akpm@...ux-foundation.org>, "david@...hat.com" <david@...hat.com>,
"lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>,
"Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>, "vbabka@...e.cz"
<vbabka@...e.cz>, "rppt@...nel.org" <rppt@...nel.org>, "surenb@...gle.com"
<surenb@...gle.com>, "mhocko@...e.com" <mhocko@...e.com>, "bp@...en8.de"
<bp@...en8.de>, "rafael@...nel.org" <rafael@...nel.org>,
"guohanjun@...wei.com" <guohanjun@...wei.com>, "mchehab@...nel.org"
<mchehab@...nel.org>, "lenb@...nel.org" <lenb@...nel.org>, "Tian, Kevin"
<kevin.tian@...el.com>, "alex@...zbot.org" <alex@...zbot.org>
CC: Neo Jia <cjia@...dia.com>, Kirti Wankhede <kwankhede@...dia.com>, "Tarun
Gupta (SW-GPU)" <targupta@...dia.com>, Zhi Wang <zhiw@...dia.com>, Dheeraj
Nigam <dnigam@...dia.com>, Krishnakant Jaju <kjaju@...dia.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-edac@...r.kernel.org"
<linux-edac@...r.kernel.org>, "Jonathan.Cameron@...wei.com"
<Jonathan.Cameron@...wei.com>, "Smita.KoralahalliChannabasappa@....com"
<Smita.KoralahalliChannabasappa@....com>, "u.kleine-koenig@...libre.com"
<u.kleine-koenig@...libre.com>, "peterz@...radead.org"
<peterz@...radead.org>, "linux-acpi@...r.kernel.org"
<linux-acpi@...r.kernel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH v3 2/3] mm: Change ghes code to allow poison of non-struct
pfn
>>> IMHO, non-struct page PFNs are common in production environments.
>>> Besides NVIDIA Grace GPU device memory, we also use reserved DRAM memory
>>> managed by a separate VMEM allocator.
>>
>> Can you elaborate on this more?
>
> We reserve a significant portion of DRAM memory at boot time using
> kernel command line parameters. This reserved memory is then managed by
>
> our internal VMEM allocator, which handles memory allocation and
> deallocation for virtual machines.
>
>To minimize memory overhead, we intentionally avoid creating struct
> pages for this reserved memory region.
Thanks Shuai for the explanation and providing the "Reviewed-by". We use
the PFNMAP for the similar reason to save on the memory usage by the
struct pages.
Also as mentioned in the 1/3 patch, I'll move this patch to the top.
Powered by blists - more mailing lists