All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Balbir Singh <bsingharora@gmail.com>,
	linux-mm@kvack.org, akpm@linux-foundation.org,
	khandual@linux.vnet.ibm.com, 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: Fri, 5 May 2017 16:52:38 +0200	[thread overview]
Message-ID: <20170505145238.GE31461@dhcp22.suse.cz> (raw)
In-Reply-To: <1493912961.25766.379.camel@kernel.crashing.org>

On Thu 04-05-17 17:49:21, Benjamin Herrenschmidt wrote:
> On Thu, 2017-05-04 at 14:52 +0200, Michal Hocko wrote:
> > 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?
> 
> Ageing isn't isn't completely broken. The ATS MMU supports
> dirty/accessed just fine.
> 
> However the TLB invalidations are quite expensive with a GPU so too
> much harvesting is detrimental, and the GPU tends to check pages out
> using a special "read with intend to write" mode, which means it almost
> always set the dirty bit if the page is writable to begin with.

This sounds pretty much like a HW specific details which is not the
right criterion to design general CDM around.

So let me repeat the fundamental question. Is the only difference from
cpuless nodes the fact that the node should be invisible to processes
unless they specify an explicit node mask? If yes then we are talking
about policy in the kernel and that sounds like a big no-no to me.
Moreover cpusets already support exclusive numa nodes AFAIR.

I am either missing something important here, and the discussion so far
hasn't helped to be honest, or this whole CDM effort tries to build a
generic interface around a _specific_ piece of HW. The matter is worse
by the fact that the described usecases are so vague that it is hard to
build a good picture whether this is generic enough that a new/different
HW will still fit into this picture.
-- 
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>

  parent reply	other threads:[~2017-05-05 14: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
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 [this message]
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=20170505145238.GE31461@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.