On 12/22/2017 10:43 PM, Dave Hansen wrote: > On 12/21/2017 07:09 PM, Anshuman Khandual wrote: >> I had presented a proposal for NUMA redesign in the Plumbers Conference this >> year where various memory devices with different kind of memory attributes >> can be represented in the kernel and be used explicitly from the user space. >> Here is the link to the proposal if you feel interested. The proposal is >> very intrusive and also I dont have a RFC for it yet for discussion here. > I think that's the best reason to "re-use NUMA" for this: it's _not_ > intrusive. > > Also, from an x86 perspective, these HMAT systems *will* be out there. > Old versions of Linux *will* see different types of memory as separate > NUMA nodes. So, if we are going to do something different, it's going > to be interesting to un-teach those systems about using the NUMA APIs > for this. That ship has sailed. I understand the need to fetch these details from ACPI/DT for applications to target these distinct memory only NUMA nodes. This can be done by parsing from platform specific values from /proc/acpi/ or /proc/device-tree/ interfaces. This can be a short term solution before NUMA redesign can be figured out. But adding generic devices like "hmat" in the /sys/devices/ path which will be locked for good, seems problematic. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
