Messages in this thread |  | | Subject | Re: [PATCH V6 0/7] ACPI: Support Generic Initiator proximity domains | From | Brice Goglin <> | Date | Fri, 20 Dec 2019 22:40:18 +0100 |
| |
Le 18/12/2019 à 15:50, Jonathan Cameron a écrit : > On Wed, 18 Dec 2019 12:32:06 +0100 > Brice Goglin <brice.goglin@gmail.com> wrote: > >> Le 16/12/2019 à 16:38, Jonathan Cameron a écrit : >>> Introduces a new type of NUMA node for cases where we want to represent >>> the access characteristics of a non CPU initiator of memory requests, >>> as these differ from all those for existing nodes containing CPUs and/or >>> memory. >>> >>> These Generic Initiators are presented by the node access0 class in >>> sysfs in the same way as a CPU. It seems likely that there will be >>> usecases in which the best 'CPU' is desired and Generic Initiators >>> should be ignored. The final few patches in this series introduced >>> access1 which is a new performance class in the sysfs node description >>> which presents only CPU to memory relationships. Test cases for this >>> are described below. >> >> Hello Jonathan >> >> If I want to test this with a fake GI, what are the minimal set of >> changes I should put in my ACPI tables? Can I just specify a dummy GI in >> SRAT? What handle should I use there? > Exactly that for a dummy GI. Also extend HMAT and SLIT for the extra > proximity domain / initiator.
I couldn't get this to work (your patches on top of 5.5-rc2). I added the GI in SRAT, and extended HMAT and SLIT accordingly.
I don't know if that's expected but I get an additional node in sysfs, with 0kB memory.
However the HMAT table gets ignored because find_mem_target() fails in hmat_parse_proximity_domain(). The target should have been allocated in alloc_memory_target() which is called in srat_parse_mem_affinity(), but it seems to me that this function isn't called for GI nodes. Or should SRAT also contain a normal Memory node with same PM as the GI?
Brice
|  |