On 07/06/2017 04:08 PM, Jerome Glisse wrote: >> 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) ? For HBM, that's certainly consistent with the Xeon Phi MCDRAM. But, please remember that this patch set is for fast memory *and* slow memory (vs. plain DRAM). > 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. You would like to take the NUMA APIs and bifurcate them? Make some of them able to work on this memory, and others not? So, set_mempolicy() would work if you passed it one of these "special" nodes with MPOL_F_ADDR, but would fail otherwise? > 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. I think the guys running 40-year-old fortran binaries might not be so keen on this restriction. I bet there are a pretty substantial number of folks out there that would love to get new hardware and just do: numactl --membind=fast-node ./old-binary If I were working for a hardware company, I'd sure like to just be able to sell somebody some fancy new hardware and have their existing software "just work" with a minimal wrapper. -- 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
