[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v6 1/2] qom: new object to associate device to numa node
From: |
Ankit Agrawal |
Subject: |
Re: [PATCH v6 1/2] qom: new object to associate device to numa node |
Date: |
Tue, 16 Jan 2024 14:02:44 +0000 |
>> >
>> > Given that, an alternative proposal that I think would work
>> > for you would be to add a 'placeholder' memory node definition
>> > in SRAT (so allow 0 size explicitly - might need a new SRAT
>> > entry to avoid backwards compat issues).
>>
>> Putting all the PCI/GI/... complexity aside, I'll just raise again that
>> for virtio-mem something simple like that might be helpful as well, IIUC.
>>
>> -numa node,nodeid=2 \
>> ...
>> -device virtio-mem-pci,node=2,... \
>>
>> All we need is the OS to prepare for an empty node that will get
>> populated with memory later.
>>
>> So if that's what a "placeholder" node definition in srat could achieve
>> as well, even without all of the other acpi-generic-initiator stuff,
>> that would be great.
>
> Please no "placeholder" definitions in SRAT. One of the main thrusts of
> CXL is to move away from static ACPI tables describing vendor-specific
> memory topology, towards an industry standard device enumeration.
So I suppose we go with the original suggestion that aligns with the
current spec description pointed by Jonathan, which is the following:
A separate acpi-generic-initiator object that links only one node to the
device. For each such association, a new object would be created.
A previously mentioned example from Jonathan:
-object acpi-generic-initiator,id=gi1,pci-dev=dev1,nodeid=10
-object acpi-generic-initiator,id=gi2,pci-dev=dev1,nodeid=11
> It is strictly OS policy about how many NUMA nodes it imagines it wants
> to define within that playground. The current OS policy is one node per
> "window". If a solution believes Linux should be creating more than that
> I submit that's a discussion with OS policy developers, not a trip to
> the BIOS team to please sprinkle in more placeholders. Linux can fully
> own the policy here. The painful bit is just that it never had to
> before.
Whilst I agree that Linux kernel solution would be nice as a long term
solution, such change could be quite involved and intrusive.
- Re: [PATCH v6 1/2] qom: new object to associate device to numa node, (continued)
- Re: [PATCH v6 1/2] qom: new object to associate device to numa node, Ankit Agrawal, 2024/01/04
- Re: [PATCH v6 1/2] qom: new object to associate device to numa node, Ankit Agrawal, 2024/01/04
- Re: [PATCH v6 1/2] qom: new object to associate device to numa node, Alex Williamson, 2024/01/04
- Re: [PATCH v6 1/2] qom: new object to associate device to numa node, Jonathan Cameron, 2024/01/09
- Re: [PATCH v6 1/2] qom: new object to associate device to numa node, David Hildenbrand, 2024/01/09
- Re: [PATCH v6 1/2] qom: new object to associate device to numa node, Jason Gunthorpe, 2024/01/09
- Re: [PATCH v6 1/2] qom: new object to associate device to numa node, Dan Williams, 2024/01/09
- Re: [PATCH v6 1/2] qom: new object to associate device to numa node, Jason Gunthorpe, 2024/01/09
- Re: [PATCH v6 1/2] qom: new object to associate device to numa node, Dan Williams, 2024/01/10
- Re: [PATCH v6 1/2] qom: new object to associate device to numa node, Michael S. Tsirkin, 2024/01/11
- Re: [PATCH v6 1/2] qom: new object to associate device to numa node,
Ankit Agrawal <=
Re: [PATCH v6 1/2] qom: new object to associate device to numa node, Alex Williamson, 2024/01/04
Re: [PATCH v6 1/2] qom: new object to associate device to numa node, Jonathan Cameron, 2024/01/09
Re: [PATCH v6 1/2] qom: new object to associate device to numa node, Markus Armbruster, 2024/01/08