| Message ID | 20240301082248.3456086-1-horenchuang@bytedance.com |
|---|---|
| Headers | show |
| Series | Improved Memory Tier Creation for CPUless NUMA Nodes | expand |
"Ho-Ren (Jack) Chuang" <horenchuang@bytedance.com> writes: > The memory tiering component in the kernel is functionally useless for > CPUless memory/non-DRAM devices like CXL1.1 type3 memory because the nodes > are lumped together in the DRAM tier. > https://lore.kernel.org/linux-mm/PH0PR08MB7955E9F08CCB64F23963B5C3A860A@PH0PR08MB7955.namprd08.prod.outlook.com/T/ I think that it's unfair to call it "useless". Yes, it doesn't work if the CXL memory device are not enumerate via drivers/dax/kmem.c. So, please be specific about in which cases it doesn't work instead of too general "useless". > This patchset automatically resolves the issues. It delays the initialization > of memory tiers for CPUless NUMA nodes until they obtain HMAT information > at boot time, eliminating the need for user intervention. > If no HMAT specified, it falls back to using `default_dram_type`. > > Example usecase: > We have CXL memory on the host, and we create VMs with a new system memory > device backed by host CXL memory. We inject CXL memory performance attributes > through QEMU, and the guest now sees memory nodes with performance attributes > in HMAT. With this change, we enable the guest kernel to construct > the correct memory tiering for the memory nodes. > > Ho-Ren (Jack) Chuang (1): > memory tier: acpi/hmat: create CPUless memory tiers after obtaining > HMAT info > > drivers/acpi/numa/hmat.c | 3 ++ > include/linux/memory-tiers.h | 6 +++ > mm/memory-tiers.c | 76 ++++++++++++++++++++++++++++++++---- > 3 files changed, 77 insertions(+), 8 deletions(-) -- Best Regards, Huang, Ying
On Fri, Mar 01, 2024 at 08:22:44AM +0000, Ho-Ren (Jack) Chuang wrote: > The memory tiering component in the kernel is functionally useless for > CPUless memory/non-DRAM devices like CXL1.1 type3 memory because the nodes > are lumped together in the DRAM tier. > https://lore.kernel.org/linux-mm/PH0PR08MB7955E9F08CCB64F23963B5C3A860A@PH0PR08MB7955.namprd08.prod.outlook.com/T/ Is this the right patchset you want to refer to? It is about node migration between tiers, how is it related to the context here? Fan > > This patchset automatically resolves the issues. It delays the initialization > of memory tiers for CPUless NUMA nodes until they obtain HMAT information > at boot time, eliminating the need for user intervention. > If no HMAT specified, it falls back to using `default_dram_type`. > > Example usecase: > We have CXL memory on the host, and we create VMs with a new system memory > device backed by host CXL memory. We inject CXL memory performance attributes > through QEMU, and the guest now sees memory nodes with performance attributes > in HMAT. With this change, we enable the guest kernel to construct > the correct memory tiering for the memory nodes. > > Ho-Ren (Jack) Chuang (1): > memory tier: acpi/hmat: create CPUless memory tiers after obtaining > HMAT info > > drivers/acpi/numa/hmat.c | 3 ++ > include/linux/memory-tiers.h | 6 +++ > mm/memory-tiers.c | 76 ++++++++++++++++++++++++++++++++---- > 3 files changed, 77 insertions(+), 8 deletions(-) > > -- > Hao Xiang and Ho-Ren (Jack) Chuang >
> -----Original Message----- > From: fan <nifan.cxl@gmail.com> > Sent: Monday, March 4, 2024 8:38 AM > To: Ho-Ren (Jack) Chuang <horenchuang@bytedance.com> > Cc: Hao Xiang <hao.xiang@bytedance.com>; Gregory Price > <gourry.memverge@gmail.com>; aneesh.kumar@linux.ibm.com; > mhocko@suse.com; tj@kernel.org; john@jagalactic.com; Eishan Mirakhur > <emirakhur@micron.com>; Vinicius Tavares Petrucci > <vtavarespetr@micron.com>; Ravis OpenSrc <Ravis.OpenSrc@micron.com>; > Alistair Popple <apopple@nvidia.com>; Rafael J. Wysocki > <rafael@kernel.org>; Len Brown <lenb@kernel.org>; Andrew Morton > <akpm@linux-foundation.org>; Dave Jiang <dave.jiang@intel.com>; Dan > Williams <dan.j.williams@intel.com>; Jonathan Cameron > <Jonathan.Cameron@huawei.com>; Huang Ying <ying.huang@intel.com>; > linux-acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > mm@kvack.org; Ho-Ren (Jack) Chuang <horenc@vt.edu>; Ho-Ren (Jack) > Chuang <horenchuang@gmail.com>; linux-cxl@vger.kernel.org; qemu- > devel@nongnu.org > Subject: [EXT] Re: [PATCH v1 0/1] Improved Memory Tier Creation for CPUless > NUMA Nodes > > CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless > you recognize the sender and were expecting this message. > > > On Fri, Mar 01, 2024 at 08:22:44AM +0000, Ho-Ren (Jack) Chuang wrote: > > The memory tiering component in the kernel is functionally useless for > > CPUless memory/non-DRAM devices like CXL1.1 type3 memory because the > nodes > > are lumped together in the DRAM tier. > > > https://lore.k/ > ernel.org%2Flinux- > mm%2FPH0PR08MB7955E9F08CCB64F23963B5C3A860A%40PH0PR08MB7955 > .namprd08.prod.outlook.com%2FT%2F&data=05%7C02%7Csthanneeru.open > src%40micron.com%7Cc4f03409bf454cca29d008dc3bf853d0%7Cf38a5ecd281 > 34862b11bac1d563c806f%7C0%7C0%7C638451185012848960%7CUnknown > %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW > wiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=syvhw1w8%2BoC6ss4%2Bu2X > HjBuyrpwFK1hIefopgVbRy7g%3D&reserved=0 > Referring to the following use case from above patch? -- 1. Useful to move cxl nodes to the right tiers from userspace, when the hardware fails to assign the tiers correctly based on memorytypes. On some platforms we have observed cxl memory being assigned to the same tier as DDR memory. This is arguably a system firmware bug, but it is true that tiers represent *ranges* of performance. and we believe it's important for the system operator to have the ability to override bad firmware or OS decisions about tier assignment as a fail-safe against potential bad outcomes. -- > Is this the right patchset you want to refer to? It is about node > migration between tiers, how is it related to the context here? > > Fan > > > > > This patchset automatically resolves the issues. It delays the initialization > > of memory tiers for CPUless NUMA nodes until they obtain HMAT > information > > at boot time, eliminating the need for user intervention. > > If no HMAT specified, it falls back to using `default_dram_type`. > > > > Example usecase: > > We have CXL memory on the host, and we create VMs with a new system > memory > > device backed by host CXL memory. We inject CXL memory performance > attributes > > through QEMU, and the guest now sees memory nodes with performance > attributes > > in HMAT. With this change, we enable the guest kernel to construct > > the correct memory tiering for the memory nodes. > > > > Ho-Ren (Jack) Chuang (1): > > memory tier: acpi/hmat: create CPUless memory tiers after obtaining > > HMAT info > > > > drivers/acpi/numa/hmat.c | 3 ++ > > include/linux/memory-tiers.h | 6 +++ > > mm/memory-tiers.c | 76 ++++++++++++++++++++++++++++++++---- > > 3 files changed, 77 insertions(+), 8 deletions(-) > > > > -- > > Hao Xiang and Ho-Ren (Jack) Chuang > >
On Sun, Mar 3, 2024 at 6:47 PM Huang, Ying <ying.huang@intel.com> wrote: > > "Ho-Ren (Jack) Chuang" <horenchuang@bytedance.com> writes: > > > The memory tiering component in the kernel is functionally useless for > > CPUless memory/non-DRAM devices like CXL1.1 type3 memory because the nodes > > are lumped together in the DRAM tier. > > https://lore.kernel.org/linux-mm/PH0PR08MB7955E9F08CCB64F23963B5C3A860A@PH0PR08MB7955.namprd08.prod.outlook.com/T/ > > I think that it's unfair to call it "useless". Yes, it doesn't work if > the CXL memory device are not enumerate via drivers/dax/kmem.c. So, > please be specific about in which cases it doesn't work instead of too > general "useless". > Thank you and I didn't mean anything specific. I simply reused phrases we discussed earlier in the previous patchset. I will change them to the following in v2: "At boot time, current memory tiering assigns all detected memory nodes to the same DRAM tier. This results in CPUless memory/non-DRAM devices, such as CXL1.1 type3 memory, being unable to be assigned to the correct memory tier, leading to the inability to migrate pages between different types of memory." Please see if this looks more specific. > > This patchset automatically resolves the issues. It delays the initialization > > of memory tiers for CPUless NUMA nodes until they obtain HMAT information > > at boot time, eliminating the need for user intervention. > > If no HMAT specified, it falls back to using `default_dram_type`. > > > > Example usecase: > > We have CXL memory on the host, and we create VMs with a new system memory > > device backed by host CXL memory. We inject CXL memory performance attributes > > through QEMU, and the guest now sees memory nodes with performance attributes > > in HMAT. With this change, we enable the guest kernel to construct > > the correct memory tiering for the memory nodes. > > > > Ho-Ren (Jack) Chuang (1): > > memory tier: acpi/hmat: create CPUless memory tiers after obtaining > > HMAT info > > > > drivers/acpi/numa/hmat.c | 3 ++ > > include/linux/memory-tiers.h | 6 +++ > > mm/memory-tiers.c | 76 ++++++++++++++++++++++++++++++++---- > > 3 files changed, 77 insertions(+), 8 deletions(-) > > -- > Best Regards, > Huang, Ying
"Ho-Ren (Jack) Chuang" <horenchuang@bytedance.com> writes: > On Sun, Mar 3, 2024 at 6:47 PM Huang, Ying <ying.huang@intel.com> wrote: >> >> "Ho-Ren (Jack) Chuang" <horenchuang@bytedance.com> writes: >> >> > The memory tiering component in the kernel is functionally useless for >> > CPUless memory/non-DRAM devices like CXL1.1 type3 memory because the nodes >> > are lumped together in the DRAM tier. >> > https://lore.kernel.org/linux-mm/PH0PR08MB7955E9F08CCB64F23963B5C3A860A@PH0PR08MB7955.namprd08.prod.outlook.com/T/ >> >> I think that it's unfair to call it "useless". Yes, it doesn't work if >> the CXL memory device are not enumerate via drivers/dax/kmem.c. So, >> please be specific about in which cases it doesn't work instead of too >> general "useless". >> > > Thank you and I didn't mean anything specific. I simply reused phrases > we discussed > earlier in the previous patchset. I will change them to the following in v2: > "At boot time, current memory tiering assigns all detected memory nodes > to the same DRAM tier. This results in CPUless memory/non-DRAM devices, > such as CXL1.1 type3 memory, being unable to be assigned to the > correct memory tier, > leading to the inability to migrate pages between different types of memory." > > Please see if this looks more specific. I don't think that the description above is accurate. In fact, there are 2 ways to enumerate the memory device, 1. Mark it as reserved memory (E820_TYPE_SOFT_RESERVED, etc.) in E820 table or something similar. 2. Mark it as normal memory (E820_TYPE_RAM) in E820 table or something similar For 1, the memory device (including CXL memory) is onlined via drivers/dax/kmem.c, so will be put in proper memory tiers. For 2, the memory device is indistinguishable with normal DRAM with current implementation. And this is what this patch is working on. Right? -- Best Regards, Huang, Ying >> > This patchset automatically resolves the issues. It delays the initialization >> > of memory tiers for CPUless NUMA nodes until they obtain HMAT information >> > at boot time, eliminating the need for user intervention. >> > If no HMAT specified, it falls back to using `default_dram_type`. >> > >> > Example usecase: >> > We have CXL memory on the host, and we create VMs with a new system memory >> > device backed by host CXL memory. We inject CXL memory performance attributes >> > through QEMU, and the guest now sees memory nodes with performance attributes >> > in HMAT. With this change, we enable the guest kernel to construct >> > the correct memory tiering for the memory nodes. >> > >> > Ho-Ren (Jack) Chuang (1): >> > memory tier: acpi/hmat: create CPUless memory tiers after obtaining >> > HMAT info >> > >> > drivers/acpi/numa/hmat.c | 3 ++ >> > include/linux/memory-tiers.h | 6 +++ >> > mm/memory-tiers.c | 76 ++++++++++++++++++++++++++++++++---- >> > 3 files changed, 77 insertions(+), 8 deletions(-) >> >> -- >> Best Regards, >> Huang, Ying
On Mon, Mar 4, 2024 at 10:36 PM Huang, Ying <ying.huang@intel.com> wrote: > > "Ho-Ren (Jack) Chuang" <horenchuang@bytedance.com> writes: > > > On Sun, Mar 3, 2024 at 6:47 PM Huang, Ying <ying.huang@intel.com> wrote: > >> > >> "Ho-Ren (Jack) Chuang" <horenchuang@bytedance.com> writes: > >> > >> > The memory tiering component in the kernel is functionally useless for > >> > CPUless memory/non-DRAM devices like CXL1.1 type3 memory because the nodes > >> > are lumped together in the DRAM tier. > >> > https://lore.kernel.org/linux-mm/PH0PR08MB7955E9F08CCB64F23963B5C3A860A@PH0PR08MB7955.namprd08.prod.outlook.com/T/ > >> > >> I think that it's unfair to call it "useless". Yes, it doesn't work if > >> the CXL memory device are not enumerate via drivers/dax/kmem.c. So, > >> please be specific about in which cases it doesn't work instead of too > >> general "useless". > >> > > > > Thank you and I didn't mean anything specific. I simply reused phrases > > we discussed > > earlier in the previous patchset. I will change them to the following in v2: > > "At boot time, current memory tiering assigns all detected memory nodes > > to the same DRAM tier. This results in CPUless memory/non-DRAM devices, > > such as CXL1.1 type3 memory, being unable to be assigned to the > > correct memory tier, > > leading to the inability to migrate pages between different types of memory." > > > > Please see if this looks more specific. > > I don't think that the description above is accurate. In fact, there > are 2 ways to enumerate the memory device, > > 1. Mark it as reserved memory (E820_TYPE_SOFT_RESERVED, etc.) in E820 > table or something similar. > > 2. Mark it as normal memory (E820_TYPE_RAM) in E820 table or something > similar > > For 1, the memory device (including CXL memory) is onlined via > drivers/dax/kmem.c, so will be put in proper memory tiers. For 2, the > memory device is indistinguishable with normal DRAM with current > implementation. And this is what this patch is working on. > > Right? Good point! How about this?: " When a memory device, such as CXL1.1 type3 memory, is emulated as normal memory (E820_TYPE_RAM), the memory device is indistinguishable from normal DRAM in terms of memory tiering with the current implementation. The current memory tiering assigns all detected normal memory nodes to the same DRAM tier. This results in normal memory devices with different attributions being unable to be assigned to the correct memory tier, leading to the inability to migrate pages between different types of memory. " -- Best regards, Ho-Ren (Jack) Chuang 莊賀任
"Ho-Ren (Jack) Chuang" <horenchuang@bytedance.com> writes: > On Mon, Mar 4, 2024 at 10:36 PM Huang, Ying <ying.huang@intel.com> wrote: >> >> "Ho-Ren (Jack) Chuang" <horenchuang@bytedance.com> writes: >> >> > On Sun, Mar 3, 2024 at 6:47 PM Huang, Ying <ying.huang@intel.com> wrote: >> >> >> >> "Ho-Ren (Jack) Chuang" <horenchuang@bytedance.com> writes: >> >> >> >> > The memory tiering component in the kernel is functionally useless for >> >> > CPUless memory/non-DRAM devices like CXL1.1 type3 memory because the nodes >> >> > are lumped together in the DRAM tier. >> >> > https://lore.kernel.org/linux-mm/PH0PR08MB7955E9F08CCB64F23963B5C3A860A@PH0PR08MB7955.namprd08.prod.outlook.com/T/ >> >> >> >> I think that it's unfair to call it "useless". Yes, it doesn't work if >> >> the CXL memory device are not enumerate via drivers/dax/kmem.c. So, >> >> please be specific about in which cases it doesn't work instead of too >> >> general "useless". >> >> >> > >> > Thank you and I didn't mean anything specific. I simply reused phrases >> > we discussed >> > earlier in the previous patchset. I will change them to the following in v2: >> > "At boot time, current memory tiering assigns all detected memory nodes >> > to the same DRAM tier. This results in CPUless memory/non-DRAM devices, >> > such as CXL1.1 type3 memory, being unable to be assigned to the >> > correct memory tier, >> > leading to the inability to migrate pages between different types of memory." >> > >> > Please see if this looks more specific. >> >> I don't think that the description above is accurate. In fact, there >> are 2 ways to enumerate the memory device, >> >> 1. Mark it as reserved memory (E820_TYPE_SOFT_RESERVED, etc.) in E820 >> table or something similar. >> >> 2. Mark it as normal memory (E820_TYPE_RAM) in E820 table or something >> similar >> >> For 1, the memory device (including CXL memory) is onlined via >> drivers/dax/kmem.c, so will be put in proper memory tiers. For 2, the >> memory device is indistinguishable with normal DRAM with current >> implementation. And this is what this patch is working on. >> >> Right? > > Good point! How about this?: > " > When a memory device, such as CXL1.1 type3 memory, is emulated as > normal memory (E820_TYPE_RAM), the memory device is indistinguishable > from normal DRAM in terms of memory tiering with the current implementation. > The current memory tiering assigns all detected normal memory nodes > to the same DRAM tier. This results in normal memory devices with > different attributions being unable to be assigned to the correct memory tier, > leading to the inability to migrate pages between different types of memory. > " Looks good me! Thanks! -- Best Regards, Huang, Ying
The memory tiering component in the kernel is functionally useless for CPUless memory/non-DRAM devices like CXL1.1 type3 memory because the nodes are lumped together in the DRAM tier. https://lore.kernel.org/linux-mm/PH0PR08MB7955E9F08CCB64F23963B5C3A860A@PH0PR08MB7955.namprd08.prod.outlook.com/T/ This patchset automatically resolves the issues. It delays the initialization of memory tiers for CPUless NUMA nodes until they obtain HMAT information at boot time, eliminating the need for user intervention. If no HMAT specified, it falls back to using `default_dram_type`. Example usecase: We have CXL memory on the host, and we create VMs with a new system memory device backed by host CXL memory. We inject CXL memory performance attributes through QEMU, and the guest now sees memory nodes with performance attributes in HMAT. With this change, we enable the guest kernel to construct the correct memory tiering for the memory nodes. Ho-Ren (Jack) Chuang (1): memory tier: acpi/hmat: create CPUless memory tiers after obtaining HMAT info drivers/acpi/numa/hmat.c | 3 ++ include/linux/memory-tiers.h | 6 +++ mm/memory-tiers.c | 76 ++++++++++++++++++++++++++++++++---- 3 files changed, 77 insertions(+), 8 deletions(-)