Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1682811
| From | Dave Hansen <dave.hansen@intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC v2 0/5] surface heterogeneous memory performance information |
| Date | 2017-07-07 01:40 +0200 |
| Message-ID | <u0oxj-3Ww-3@gated-at.bofh.it> (permalink) |
| References | <u0mYx-2Sz-3@gated-at.bofh.it> <u0o4i-3Nh-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC v2 0/5] surface heterogeneous memory performance information Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-07-07 00:00 +0200
[RFC v2 3/5] hmem: add heterogeneous memory sysfs support Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-07-07 00:00 +0200
Re: [RFC v2 3/5] hmem: add heterogeneous memory sysfs support John Hubbard <jhubbard@nvidia.com> - 2017-07-07 08:00 +0200
Re: [RFC v2 3/5] hmem: add heterogeneous memory sysfs support Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-07-07 18:40 +0200
[RFC v2 5/5] hmem: add performance attributes Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-07-07 00:00 +0200
[RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array() Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-07-07 00:00 +0200
Re: [RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array() "Rafael J. Wysocki" <rafael@kernel.org> - 2017-07-07 00:20 +0200
Re: [RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array() Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-07-07 00:30 +0200
Re: [RFC v2 2/5] acpi: HMAT support in acpi_parse_entries_array() "Rafael J. Wysocki" <rafael@kernel.org> - 2017-07-07 00:40 +0200
[RFC v2 1/5] acpi: add missing include in acpi_numa.h Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-07-07 00:00 +0200
Re: [RFC v2 1/5] acpi: add missing include in acpi_numa.h "Rafael J. Wysocki" <rafael@kernel.org> - 2017-07-07 00:10 +0200
Re: [RFC v2 0/5] surface heterogeneous memory performance information Jerome Glisse <jglisse@redhat.com> - 2017-07-07 01:10 +0200
Re: [RFC v2 0/5] surface heterogeneous memory performance information Dave Hansen <dave.hansen@intel.com> - 2017-07-07 01:40 +0200
Re: [RFC v2 0/5] surface heterogeneous memory performance information John Hubbard <jhubbard@nvidia.com> - 2017-07-07 07:40 +0200
Re: [RFC v2 0/5] surface heterogeneous memory performance information Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-07-07 18:40 +0200
Re: [RFC v2 0/5] surface heterogeneous memory performance information Balbir Singh <bsingharora@gmail.com> - 2017-07-07 08:30 +0200
Re: [RFC v2 0/5] surface heterogeneous memory performance information Dave Hansen <dave.hansen@intel.com> - 2017-07-07 18:30 +0200
Re: [RFC v2 0/5] surface heterogeneous memory performance information Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-07-07 18:30 +0200
csiph-web