From: Jerome Glisse <jglisse@redhat.com>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-mm@kvack.org, Dan Williams <dan.j.williams@intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Felix Kuehling <Felix.Kuehling@amd.com>,
John Hubbard <jhubbard@nvidia.com>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
Keith Busch <keith.busch@intel.com>,
Mel Gorman <mgorman@techsingularity.net>,
Michal Hocko <mhocko@kernel.org>,
Paul Blinzer <Paul.Blinzer@amd.com>,
linux-kernel@vger.kernel.org
Subject: Re: [LSF/MM TOPIC] NUMA, memory hierarchy and device memory
Date: Thu, 25 Apr 2019 16:16:24 -0400 [thread overview]
Message-ID: <20190425201623.GB6391@redhat.com> (raw)
In-Reply-To: <20190118174512.GA3060@redhat.com>
I see that the schedule is not full yet for the mm track and i would
really like to be able to have a discussion on this topic
Schedule:
https://docs.google.com/spreadsheets/d/1Z1pDL-XeUT1ZwMWrBL8T8q3vtSqZpLPgF3Bzu_jejfk/edit#gid=0
On Fri, Jan 18, 2019 at 12:45:13PM -0500, Jerome Glisse wrote:
> Hi, i would like to discuss about NUMA API and its short comings when
> it comes to memory hierarchy (from fast HBM, to slower persistent
> memory through regular memory) and also device memory (which can have
> its own hierarchy).
>
> I have proposed a patch to add a new memory topology model to the
> kernel for application to be able to get that informations, it
> also included a set of new API to bind/migrate process range [1].
> Note that this model also support device memory.
>
> So far device memory support is achieve through device specific ioctl
> and this forbid some scenario like device memory interleaving accross
> multiple devices for a range. It also make the whole userspace more
> complex as program have to mix and match multiple device specific API
> on top of NUMA API.
>
> While memory hierarchy can be more or less expose through the existing
> NUMA API by creating node for non-regular memory [2], i do not see this
> as a satisfying solution. Moreover such scheme does not work for device
> memory that might not even be accessible by CPUs.
>
>
> Hence i would like to discuss few points:
> - What proof people wants to see this as problem we need to solve ?
> - How to build concensus to move forward on this ?
> - What kind of syscall API people would like to see ?
>
> People to discuss this topic:
> Dan Williams <dan.j.williams@intel.com>
> Dave Hansen <dave.hansen@intel.com>
> Felix Kuehling <Felix.Kuehling@amd.com>
> John Hubbard <jhubbard@nvidia.com>
> Jonathan Cameron <jonathan.cameron@huawei.com>
> Keith Busch <keith.busch@intel.com>
> Mel Gorman <mgorman@techsingularity.net>
> Michal Hocko <mhocko@kernel.org>
> Paul Blinzer <Paul.Blinzer@amd.com>
>
> Probably others, sorry if i miss anyone from previous discussions.
>
> Cheers,
> Jérôme
>
> [1] https://lkml.org/lkml/2018/12/3/1072
> [2] https://lkml.org/lkml/2018/12/10/1112
>
prev parent reply other threads:[~2019-04-25 20:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-18 17:45 [LSF/MM TOPIC] NUMA, memory hierarchy and device memory Jerome Glisse
2019-02-22 14:31 ` Jonathan Cameron
2019-04-25 20:16 ` Jerome Glisse [this message]
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=20190425201623.GB6391@redhat.com \
--to=jglisse@redhat.com \
--cc=Felix.Kuehling@amd.com \
--cc=Paul.Blinzer@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=jhubbard@nvidia.com \
--cc=jonathan.cameron@huawei.com \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
/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.