From: Dan Williams <dan.j.williams@intel.com>
To: Bob Liu <liubo95@huawei.com>
Cc: Jerome Glisse <jglisse@redhat.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>, John Hubbard <jhubbard@nvidia.com>,
David Nellans <dnellans@nvidia.com>,
Balbir Singh <bsingharora@gmail.com>,
majiuyue <majiuyue@huawei.com>,
"xieyisheng (A)" <xieyisheng1@huawei.com>
Subject: Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3
Date: Fri, 8 Sep 2017 13:43:05 -0700 [thread overview]
Message-ID: <CAPcyv4iWPG9wVqe1GW+Ewk4rqELZB6SRR=sF0G8NaabUu2jH_w@mail.gmail.com> (raw)
In-Reply-To: <863afc77-ed84-fed5-ebb8-d88e636816a3@huawei.com>
On Thu, Sep 7, 2017 at 6:59 PM, Bob Liu <liubo95@huawei.com> wrote:
> On 2017/9/8 1:27, Jerome Glisse wrote:
[..]
>> No this are 2 orthogonal thing, they do not conflict with each others quite
>> the contrary. HMM (the CDM part is no different) is a set of helpers, see
>> it as a toolbox, for device driver.
>>
>> HMAT is a way for firmware to report memory resources with more informations
>> that just range of physical address. HMAT is specific to platform that rely
>> on ACPI. HMAT does not provide any helpers to manage these memory.
>>
>> So a device driver can get informations about device memory from HMAT and then
>> use HMM to help in managing and using this memory.
>>
>
> Yes, but as Balbir mentioned requires :
> 1. Don't online the memory as a NUMA node
> 2. Use the HMM-CDM API's to map the memory to ZONE DEVICE via the driver
>
> And I'm not sure whether Intel going to use this HMM-CDM based method for their "target domain" memory ?
> Or they prefer to NUMA approach? Ross？ Dan?
The starting / strawman proposal for performance differentiated memory
ranges is to get platform firmware to mark them reserved by default.
Then, after we parse the HMAT, make them available via the device-dax
mechanism so that applications that need 100% guaranteed access to
these potentially high-value / limited-capacity ranges can be sure to
get them by default, i.e. before any random kernel objects are placed
in them. Otherwise, if there are no dedicated users for the memory
ranges via device-dax, or they don't need the total capacity, we want
to hotplug that memory into the general purpose memory allocator with
a numa node number so typical numactl and memory-management flows are
enabled.
Ideally this would not be specific to HMAT and any agent that knows
differentiated performance characteristics of a memory range could use
this scheme.
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Bob Liu <liubo95@huawei.com>
Cc: Jerome Glisse <jglisse@redhat.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>, John Hubbard <jhubbard@nvidia.com>,
David Nellans <dnellans@nvidia.com>,
Balbir Singh <bsingharora@gmail.com>,
majiuyue <majiuyue@huawei.com>,
"xieyisheng (A)" <xieyisheng1@huawei.com>
Subject: Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3
Date: Fri, 8 Sep 2017 13:43:05 -0700 [thread overview]
Message-ID: <CAPcyv4iWPG9wVqe1GW+Ewk4rqELZB6SRR=sF0G8NaabUu2jH_w@mail.gmail.com> (raw)
In-Reply-To: <863afc77-ed84-fed5-ebb8-d88e636816a3@huawei.com>
On Thu, Sep 7, 2017 at 6:59 PM, Bob Liu <liubo95@huawei.com> wrote:
> On 2017/9/8 1:27, Jerome Glisse wrote:
[..]
>> No this are 2 orthogonal thing, they do not conflict with each others quite
>> the contrary. HMM (the CDM part is no different) is a set of helpers, see
>> it as a toolbox, for device driver.
>>
>> HMAT is a way for firmware to report memory resources with more informations
>> that just range of physical address. HMAT is specific to platform that rely
>> on ACPI. HMAT does not provide any helpers to manage these memory.
>>
>> So a device driver can get informations about device memory from HMAT and then
>> use HMM to help in managing and using this memory.
>>
>
> Yes, but as Balbir mentioned requires :
> 1. Don't online the memory as a NUMA node
> 2. Use the HMM-CDM API's to map the memory to ZONE DEVICE via the driver
>
> And I'm not sure whether Intel going to use this HMM-CDM based method for their "target domain" memory ?
> Or they prefer to NUMA approach? Ross？ Dan?
The starting / strawman proposal for performance differentiated memory
ranges is to get platform firmware to mark them reserved by default.
Then, after we parse the HMAT, make them available via the device-dax
mechanism so that applications that need 100% guaranteed access to
these potentially high-value / limited-capacity ranges can be sure to
get them by default, i.e. before any random kernel objects are placed
in them. Otherwise, if there are no dedicated users for the memory
ranges via device-dax, or they don't need the total capacity, we want
to hotplug that memory into the general purpose memory allocator with
a numa node number so typical numactl and memory-management flows are
enabled.
Ideally this would not be specific to HMAT and any agent that knows
differentiated performance characteristics of a memory range could use
this scheme.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-09-08 20:43 UTC|newest]
Thread overview: 119+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-17 0:05 [HMM-v25 00/19] HMM (Heterogeneous Memory Management) v25 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 01/19] hmm: heterogeneous memory management documentation v3 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 02/19] mm/hmm: heterogeneous memory management (HMM for short) v5 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 03/19] mm/hmm/mirror: mirror process address space on device with HMM helpers v3 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 04/19] mm/hmm/mirror: helper to snapshot CPU page table v4 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 05/19] mm/hmm/mirror: device page fault handler Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 06/19] mm/memory_hotplug: introduce add_pages Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 07/19] mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory v5 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2018-12-20 8:33 ` Dan Williams
2018-12-20 16:15 ` Jerome Glisse
2018-12-20 16:15 ` Jerome Glisse
2018-12-20 16:47 ` Dan Williams
2018-12-20 16:47 ` Dan Williams
2018-12-20 16:57 ` Jerome Glisse
2018-12-20 16:57 ` Jerome Glisse
2017-08-17 0:05 ` [HMM-v25 08/19] mm/ZONE_DEVICE: special case put_page() for device private pages v4 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 09/19] mm/memcontrol: allow to uncharge page without using page->lru field Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 10/19] mm/memcontrol: support MEMORY_DEVICE_PRIVATE v4 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-09-05 17:13 ` Laurent Dufour
2017-09-05 17:13 ` Laurent Dufour
2017-09-05 17:13 ` Laurent Dufour
2017-09-05 17:21 ` Jerome Glisse
2017-09-05 17:21 ` Jerome Glisse
2017-08-17 0:05 ` [HMM-v25 11/19] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE v7 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 12/19] mm/hmm/devmem: dummy HMM device for ZONE_DEVICE memory v3 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 13/19] mm/migrate: new migrate mode MIGRATE_SYNC_NO_COPY Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 21:12 ` Andrew Morton
2017-08-17 21:12 ` Andrew Morton
2017-08-17 21:44 ` Jerome Glisse
2017-08-17 21:44 ` Jerome Glisse
2017-08-17 0:05 ` [HMM-v25 14/19] mm/migrate: new memory migration helper for use with device memory v5 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 15/19] mm/migrate: migrate_vma() unmap page from vma while collecting pages Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 16/19] mm/migrate: support un-addressable ZONE_DEVICE page in migration v3 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 17/19] mm/migrate: allow migrate_vma() to alloc new page on empty entry v4 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 18/19] mm/device-public-memory: device memory cache coherent with CPU v5 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-08-17 0:05 ` [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3 Jérôme Glisse
2017-08-17 0:05 ` Jérôme Glisse
2017-09-04 3:09 ` Bob Liu
2017-09-04 3:09 ` Bob Liu
2017-09-04 15:51 ` Jerome Glisse
2017-09-04 15:51 ` Jerome Glisse
2017-09-05 1:13 ` Bob Liu
2017-09-05 1:13 ` Bob Liu
2017-09-05 2:38 ` Jerome Glisse
2017-09-05 2:38 ` Jerome Glisse
2017-09-05 3:50 ` Bob Liu
2017-09-05 3:50 ` Bob Liu
2017-09-05 13:50 ` Jerome Glisse
2017-09-05 13:50 ` Jerome Glisse
2017-09-05 16:18 ` Dan Williams
2017-09-05 16:18 ` Dan Williams
2017-09-05 19:00 ` Ross Zwisler
2017-09-05 19:00 ` Ross Zwisler
2017-09-05 19:20 ` Jerome Glisse
2017-09-05 19:20 ` Jerome Glisse
2017-09-08 19:43 ` Ross Zwisler
2017-09-08 19:43 ` Ross Zwisler
2017-09-08 20:29 ` Jerome Glisse
2017-09-08 20:29 ` Jerome Glisse
2017-09-05 18:54 ` Ross Zwisler
2017-09-05 18:54 ` Ross Zwisler
2017-09-06 1:25 ` Bob Liu
2017-09-06 1:25 ` Bob Liu
2017-09-06 2:12 ` Jerome Glisse
2017-09-06 2:12 ` Jerome Glisse
2017-09-07 2:06 ` Bob Liu
2017-09-07 2:06 ` Bob Liu
2017-09-07 17:00 ` Jerome Glisse
2017-09-07 17:00 ` Jerome Glisse
2017-09-07 17:27 ` Jerome Glisse
2017-09-07 17:27 ` Jerome Glisse
2017-09-08 1:59 ` Bob Liu
2017-09-08 1:59 ` Bob Liu
2017-09-08 20:43 ` Dan Williams [this message]
2017-09-08 20:43 ` Dan Williams
2017-11-17 3:47 ` chetan L
2017-11-17 3:47 ` chetan L
2017-09-05 3:36 ` Balbir Singh
2017-09-05 3:36 ` Balbir Singh
2017-08-17 21:39 ` [HMM-v25 00/19] HMM (Heterogeneous Memory Management) v25 Andrew Morton
2017-08-17 21:39 ` Andrew Morton
2017-08-17 21:55 ` Jerome Glisse
2017-08-17 21:55 ` Jerome Glisse
2017-08-17 21:59 ` Dan Williams
2017-08-17 21:59 ` Dan Williams
2017-08-17 22:02 ` Jerome Glisse
2017-08-17 22:02 ` Jerome Glisse
2017-08-17 22:06 ` Dan Williams
2017-08-17 22:06 ` Dan Williams
2017-08-17 22:16 ` Andrew Morton
2017-08-17 22:16 ` Andrew Morton
2017-12-13 12:10 ` Figo.zhang
2017-12-13 16:12 ` Jerome Glisse
2017-12-14 2:48 ` Figo.zhang
2017-12-14 3:16 ` Jerome Glisse
2017-12-14 3:53 ` Figo.zhang
2017-12-14 4:16 ` Jerome Glisse
2017-12-14 7:05 ` Figo.zhang
2017-12-14 15:28 ` Jerome Glisse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPcyv4iWPG9wVqe1GW+Ewk4rqELZB6SRR=sF0G8NaabUu2jH_w@mail.gmail.com' \
--to=dan.j.williams@intel.com \
--cc=akpm@linux-foundation.org \
--cc=bsingharora@gmail.com \
--cc=dnellans@nvidia.com \
--cc=jglisse@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liubo95@huawei.com \
--cc=majiuyue@huawei.com \
--cc=ross.zwisler@linux.intel.com \
--cc=xieyisheng1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.