On Thu, Jul 06, 2017 at 03:52:28PM -0600, Ross Zwisler wrote: [...] > > ==== Next steps ==== > > There is still a lot of work to be done on this series, but the overall > goal of this RFC is to gather feedback on which of the two options we > should pursue, or whether some third option is preferred. After that is > done and we have a solid direction we can add support for ACPI hot add, > test more complex configurations, etc. > > So, for applications that need to differentiate between memory ranges based > on their performance, what option would work best for you? Is the local > (initiator,target) performance provided by patch 5 enough, or do you > require performance information for all possible (initiator,target) > pairings? Am i right in assuming that HBM or any faster memory will be relatively small (1GB - 8GB maybe 16GB ?) and of fix amount (ie size will depend on the exact CPU model you have) ? If so i am wondering if we should not restrict NUMA placement policy for such node to vma only. Forbid any policy that would prefer those node globally at thread/process level. This would avoid wide thread policy to exhaust this smaller pool of memory. Drawback of doing so would be that existing applications would not benefit from it. So workload where is acceptable to exhaust such memory wouldn't benefit until their application are updated. This is definitly not something impacting this patchset. I am just thinking about this at large and i believe that NUMA might need to evolve slightly to better handle memory hierarchy. Cheers, Jérôme -- 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
