All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Balbir Singh <bsingharora@gmail.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
	khandual@linux.vnet.ibm.com, benh@kernel.crashing.org,
	aneesh.kumar@linux.vnet.ibm.com, paulmck@linux.vnet.ibm.com,
	srikar@linux.vnet.ibm.com, haren@linux.vnet.ibm.com,
	jglisse@redhat.com, mgorman@techsingularity.net,
	mhocko@kernel.org, arbab@linux.vnet.ibm.com, vbabka@suse.cz
Subject: Re: [RFC 0/4] RFC - Coherent Device Memory (Not for inclusion)
Date: Thu, 20 Apr 2017 10:29:52 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.20.1704201025360.26403@east.gentwo.org> (raw)
In-Reply-To: <1492651508.1015.2.camel@gmail.com>

On Thu, 20 Apr 2017, Balbir Singh wrote:
> Couple of things are needed
>
> 1. Isolation of allocation

cgroups, memory policy and cpuset provide that

> 2. Isolation of certain algorithms like kswapd/auto-numa balancing

Ok that may mean adding some generic functionality to limit those

> > The approach sounds pretty invasive to me.
>
> Could you please elaborate, you mean the user space programming bits?

No I mean the modification of the memory policies in particular. We are
adding more exceptions to an already complex and fragile system.

Can we do this in a generic way just using hotplug nodes and some of the
existing isolation mechanisms?


> Ideally we need the following:
>
> 1. Transparency about being able to allocate memory anywhere and the ability
> to migrate memory between coherent device memory and normal system memory

If it is a memory node then you have that already.

> 2. The ability to explictly allocate memory from coherent device memory

Ditto

> 3. Isolation of normal allocations from coherent device memory unless
> explictly stated, same as (2) above

memory policies etc do that.

> 4. The ability to hotplug in and out the memory at run-time

hotplug code does that.


> 5. Exchange pointers between coherent device memory and normal memory
> for the compute on the coherent device memory to use

I dont see anything preventing that from occurring right now. Thats a
device issue with doing proper virtual to physical mapping right?

> I could list further things, but largely coherent device memory is like
> system memory except that we believe that things like auto-numa balancing
> and kswapd will not work well due to lack of information about references
> and faults.

Ok so far I do not see that we need coherent nodes at all.

> Some of the mm-summit notes are at https://lwn.net/Articles/717601/
> The goals align with HMM, except that the device memory is coherent. HMM
> has a CDM variation as well.

I was at the presentation but at that point you were interested in a
different approach it seems.

> We've been using the term coherent device memory (CDM). I could rephrase the
> text and documentation for consistency. Would you prefer a different term?

Hotplug memory node?

--
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>

  reply	other threads:[~2017-04-20 15:29 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-19  7:52 [RFC 0/4] RFC - Coherent Device Memory (Not for inclusion) Balbir Singh
2017-04-19  7:52 ` [RFC 1/4] mm: create N_COHERENT_MEMORY Balbir Singh
2017-04-27 18:42   ` Reza Arbab
2017-04-28  5:07     ` Balbir Singh
2017-04-19  7:52 ` [RFC 2/4] arch/powerpc/mm: add support for coherent memory Balbir Singh
2017-04-19  7:52 ` [RFC 3/4] mm: Integrate N_COHERENT_MEMORY with mempolicy and the rest of the system Balbir Singh
2017-04-19  7:52 ` [RFC 4/4] mm: Add documentation for coherent memory Balbir Singh
2017-04-19 19:02 ` [RFC 0/4] RFC - Coherent Device Memory (Not for inclusion) Christoph Lameter
2017-04-20  1:25   ` Balbir Singh
2017-04-20 15:29     ` Christoph Lameter [this message]
2017-04-20 21:26       ` Benjamin Herrenschmidt
2017-04-21 16:13         ` Christoph Lameter
2017-04-21 21:15           ` Benjamin Herrenschmidt
2017-04-24 13:57             ` Christoph Lameter
2017-04-24  0:20       ` Balbir Singh
2017-04-24 14:00         ` Christoph Lameter
2017-04-25  0:52           ` Balbir Singh
2017-05-01 20:41 ` John Hubbard
2017-05-01 21:04   ` Reza Arbab
2017-05-01 21:56     ` John Hubbard
2017-05-01 23:51       ` Reza Arbab
2017-05-01 23:58         ` John Hubbard
2017-05-02  0:04           ` Reza Arbab
2017-05-02  1:29   ` Balbir Singh
2017-05-02  5:47     ` John Hubbard
2017-05-02  7:23       ` Balbir Singh
2017-05-02 17:50         ` John Hubbard
2017-05-02 14:36 ` Michal Hocko
2017-05-04  5:26   ` Balbir Singh
2017-05-04 12:52     ` Michal Hocko
2017-05-04 15:49       ` Benjamin Herrenschmidt
2017-05-04 17:33         ` Dave Hansen
2017-05-05  3:17           ` Balbir Singh
2017-05-05 14:51             ` Dave Hansen
2017-05-05  7:49           ` Benjamin Herrenschmidt
2017-05-05 14:52         ` Michal Hocko
2017-05-05 15:57           ` Benjamin Herrenschmidt
2017-05-05 17:48             ` Jerome Glisse
2017-05-05 17:59               ` Benjamin Herrenschmidt
2017-05-09 11:36             ` Michal Hocko
2017-05-09 13:43               ` Benjamin Herrenschmidt
2017-05-15 12:55                 ` Michal Hocko
2017-05-15 15:53                   ` Christoph Lameter
2017-05-10 23:04               ` Balbir Singh
2017-05-09  7:51           ` Balbir Singh

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=alpine.DEB.2.20.1704201025360.26403@east.gentwo.org \
    --to=cl@linux.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=arbab@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=bsingharora@gmail.com \
    --cc=haren@linux.vnet.ibm.com \
    --cc=jglisse@redhat.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=vbabka@suse.cz \
    /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.