All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.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,
	arbab@linux.vnet.ibm.com, vbabka@suse.cz, cl@linux.com
Subject: Re: [RFC 0/4] RFC - Coherent Device Memory (Not for inclusion)
Date: Thu, 4 May 2017 14:52:50 +0200	[thread overview]
Message-ID: <20170504125250.GH31540@dhcp22.suse.cz> (raw)
In-Reply-To: <1493875615.7934.1.camel@gmail.com>

On Thu 04-05-17 15:26:55, Balbir Singh wrote:
> On Tue, 2017-05-02 at 16:36 +0200, Michal Hocko wrote:
> > On Wed 19-04-17 17:52:38, Balbir Singh wrote:
[...]
> > > 2. kswapd reclaim
> > 
> > How is the memory reclaim handled then? How are users expected to handle
> > OOM situation?
> > 
> 
> 1. The fallback node list for coherent memory includes regular memory
>    nodes
> 2. Direct reclaim works, I've tested it

But the direct reclaim would be effective only _after_ all other nodes
are full.

I thought that kswapd reclaim is a problem because the HW doesn't
support aging properly but as the direct reclaim works then what is the
actual problem?
 
> > > The reason for exposing this device memory as NUMA is to simplify
> > > the programming model, where memory allocation via malloc() or
> > > mmap() for example would seamlessly work across both kinds of
> > > memory. Since we expect the size of device memory to be smaller
> > > than system RAM, we would like to control the allocation of such
> > > memory. The proposed mechanism reuses nodemasks and explicit
> > > specification of the coherent node in the nodemask for allocation
> > > from device memory. This implementation also allows for kernel
> > > level allocation via __GFP_THISNODE and existing techniques
> > > such as page migration to work.
> > 
> > so it basically resembles isol_cpus except for memory, right. I believe
> > scheduler people are more than unhappy about this interface...
> >
> 
> isol_cpus were for an era when timer/interrupts and other scheduler
> infrastructure present today was not around, but I don't mean to digress.

AFAIU, it has been added to _isolate_ some cpus from the scheduling domain
and have them available for the explicit affinity usage. You are
effectivelly proposing the same thing.

-- 
Michal Hocko
SUSE Labs

--
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-05-04 12:52 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
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 [this message]
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=20170504125250.GH31540@dhcp22.suse.cz \
    --to=mhocko@suse.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=cl@linux.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=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.