Re: [RFC v2 0/5] surface heterogeneous memory performance information

2017-07-19 Thread Dave Hansen
On 07/19/2017 02:48 AM, Bob Liu wrote: >> Option 2: Provide the user with HMAT performance data directly in >> sysfs, allowing applications to directly access it without the need >> for the library and daemon. >> > Is it possible to do the memory allocation automatically by the > kernel and transp

Re: [RFC v2 0/5] surface heterogeneous memory performance information

2017-07-19 Thread Bob Liu
On 2017/7/7 5:52, Ross Zwisler wrote: > Quick Summary > > Platforms in the very near future will have multiple types of memory > attached to a single CPU. These disparate memory ranges will have some > characteristics in common, such as CPU cache coherence, but they can have > wide rang

Re: [RFC v2 0/5] surface heterogeneous memory performance information

2017-07-07 Thread Ross Zwisler
On Thu, Jul 06, 2017 at 10:30:46PM -0700, John Hubbard wrote: > On 07/06/2017 02:52 PM, Ross Zwisler wrote: > [...] > > > > The naming collision between Jerome's "Heterogeneous Memory Management > > (HMM)" and this "Heterogeneous Memory (HMEM)" series is unfortunate, but I > > was trying to stick

Re: [RFC v2 0/5] surface heterogeneous memory performance information

2017-07-07 Thread Ross Zwisler
On Fri, Jul 07, 2017 at 04:27:16PM +1000, Balbir Singh wrote: > On Thu, 2017-07-06 at 15:52 -0600, Ross Zwisler wrote: > > Quick Summary > > > > Platforms in the very near future will have multiple types of memory > > attached to a single CPU. These disparate memory ranges will have som

Re: [RFC v2 0/5] surface heterogeneous memory performance information

2017-07-07 Thread Dave Hansen
On 07/06/2017 11:27 PM, Balbir Singh wrote: > On Thu, 2017-07-06 at 15:52 -0600, Ross Zwisler wrote: >> # grep . mem_tgt2/* mem_tgt2/local_init/* 2>/dev/null >> mem_tgt2/firmware_id:1 This is here for folks that know their platform and know exactly the firmware ID (PXM in ACPI parlance) of a g

Re: [RFC v2 0/5] surface heterogeneous memory performance information

2017-07-06 Thread Balbir Singh
On Thu, 2017-07-06 at 15:52 -0600, Ross Zwisler wrote: > Quick Summary > > Platforms in the very near future will have multiple types of memory > attached to a single CPU. These disparate memory ranges will have some > characteristics in common, such as CPU cache coherence, but they can

Re: [RFC v2 0/5] surface heterogeneous memory performance information

2017-07-06 Thread John Hubbard
On 07/06/2017 02:52 PM, Ross Zwisler wrote: [...] > > The naming collision between Jerome's "Heterogeneous Memory Management > (HMM)" and this "Heterogeneous Memory (HMEM)" series is unfortunate, but I > was trying to stick with the word "Heterogeneous" because of the naming of > the ACPI 6.2 Hete

Re: [RFC v2 0/5] surface heterogeneous memory performance information

2017-07-06 Thread Dave Hansen
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 info

Re: [RFC v2 0/5] surface heterogeneous memory performance information

2017-07-06 Thread Jerome Glisse
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 prefe

[RFC v2 0/5] surface heterogeneous memory performance information

2017-07-06 Thread Ross Zwisler
Quick Summary Platforms in the very near future will have multiple types of memory attached to a single CPU. These disparate memory ranges will have some characteristics in common, such as CPU cache coherence, but they can have wide ranges of performance both in terms of latency and ban