From: Christoph Lameter <cl@linux.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Jerome Glisse <j.glisse@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
jglisse@redhat.com, mgorman@suse.de, aarcange@redhat.com,
riel@redhat.com, airlied@redhat.com, benh@kernel.crashing.org,
aneesh.kumar@linux.vnet.ibm.com,
Cameron Buschardt <cabuschardt@nvidia.com>,
Mark Hairgrove <mhairgrove@nvidia.com>,
Geoffrey Gerfin <ggerfin@nvidia.com>,
John McKenna <jmckenna@nvidia.com>,
akpm@linux-foundation.org
Subject: Re: Interacting with coherent memory on external devices
Date: Wed, 22 Apr 2015 11:16:49 -0500 (CDT) [thread overview]
Message-ID: <alpine.DEB.2.11.1504221105130.24979@gentwo.org> (raw)
In-Reply-To: <20150422131832.GU5561@linux.vnet.ibm.com>
On Wed, 22 Apr 2015, Paul E. McKenney wrote:
> I completely agree that some critically important use cases, such as
> yours, will absolutely require that the application explicitly choose
> memory placement and have the memory stay there.
Most of what you are trying to do here is already there and has been done.
GPU memory is accessible. NICs work etc etc. All without CAPI. What
exactly are the benefits of CAPI? Is driver simplification? Reduction of
overhead? If so then the measures proposed are a bit radical and
may result in just the opposite.
For my use cases the advantage of CAPI lies in the reduction of latency
for coprocessor communication. I hope that CAPI will allow fast cache to
cache transactions between a coprocessor and the main one. This is
improving the ability to exchange data rapidly between a application code
and some piece of hardware (NIC, GPU, custom hardware etc etc)
Fundamentally this is currently an design issue since CAPI is running on
top of PCI-E and PCI-E transactions establish a minimum latency that
cannot be avoided. So its hard to see how CAPI can improve the situation.
The new thing about CAPI are the cache to cache transactions and
participation in cache coherency at the cacheline level. That is a
different approach than the device memory oriented PCI transcactions.
Perhaps even CAPI over PCI-E can improve the situation there (maybe the
transactions are lower latency than going to device memory) and hopefully
CAPI will not forever be bound to PCI-E and thus at some point shake off
the shackles of a bus designed by a competitor.
--
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:[~2015-04-22 16:16 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-21 21:44 Paul E. McKenney
2015-04-21 23:46 ` Jerome Glisse
2015-04-22 0:36 ` Benjamin Herrenschmidt
2015-04-22 12:42 ` Paul E. McKenney
2015-04-21 23:49 ` Christoph Lameter
2015-04-22 0:05 ` Jerome Glisse
2015-04-22 0:50 ` Christoph Lameter
2015-04-22 1:01 ` Benjamin Herrenschmidt
2015-04-22 13:35 ` Paul E. McKenney
2015-04-22 13:18 ` Paul E. McKenney
2015-04-22 16:16 ` Christoph Lameter [this message]
2015-04-22 17:07 ` Jerome Glisse
2015-04-22 18:17 ` Christoph Lameter
2015-04-22 18:52 ` Paul E. McKenney
2015-04-23 14:12 ` Christoph Lameter
2015-04-23 19:24 ` Paul E. McKenney
2015-04-24 14:01 ` Christoph Lameter
2015-04-24 14:13 ` Paul E. McKenney
2015-04-24 15:53 ` Rik van Riel
2015-04-23 2:36 ` Benjamin Herrenschmidt
2015-04-23 14:10 ` Christoph Lameter
2015-04-23 15:42 ` Jerome Glisse
2015-04-24 14:04 ` Christoph Lameter
2015-04-23 22:29 ` Benjamin Herrenschmidt
2015-04-23 2:30 ` Benjamin Herrenschmidt
2015-04-23 14:25 ` Christoph Lameter
2015-04-23 15:25 ` Austin S Hemmelgarn
2015-04-23 19:33 ` Paul E. McKenney
2015-04-24 14:12 ` Christoph Lameter
2015-04-24 14:57 ` Paul E. McKenney
2015-04-24 15:09 ` Jerome Glisse
2015-04-25 11:20 ` Paul E. McKenney
2015-04-24 15:52 ` Christoph Lameter
2015-04-23 22:37 ` Benjamin Herrenschmidt
2015-04-24 14:09 ` Christoph Lameter
2015-04-23 16:04 ` Rik van Riel
2015-04-22 0:42 ` Benjamin Herrenschmidt
2015-04-22 0:57 ` Paul E. McKenney
2015-04-22 1:04 ` Benjamin Herrenschmidt
2015-04-22 15:25 ` Christoph Lameter
2015-04-22 16:31 ` Jerome Glisse
2015-04-22 17:14 ` Christoph Lameter
2015-04-22 19:07 ` Jerome Glisse
2015-04-23 2:34 ` Benjamin Herrenschmidt
2015-04-23 14:38 ` Christoph Lameter
2015-04-23 16:11 ` Jerome Glisse
2015-04-24 14:29 ` Christoph Lameter
2015-04-24 15:08 ` Jerome Glisse
2015-04-24 16:03 ` Christoph Lameter
2015-04-24 16:43 ` Jerome Glisse
2015-04-24 16:58 ` Christoph Lameter
2015-04-24 17:19 ` Jerome Glisse
2015-04-24 18:56 ` Christoph Lameter
2015-04-24 19:29 ` Jerome Glisse
2015-04-24 20:00 ` Christoph Lameter
2015-04-24 20:32 ` Jerome Glisse
2015-04-25 11:46 ` Paul E. McKenney
2015-04-27 15:08 ` Christoph Lameter
2015-04-27 15:47 ` Jerome Glisse
2015-04-27 16:17 ` Christoph Lameter
2015-04-27 16:29 ` Rik van Riel
2015-04-27 16:48 ` Christoph Lameter
2015-04-27 23:54 ` Benjamin Herrenschmidt
2015-05-13 14:10 ` Vlastimil Babka
2015-05-13 23:38 ` Benjamin Herrenschmidt
2015-05-14 7:39 ` Vlastimil Babka
2015-05-14 7:51 ` Benjamin Herrenschmidt
2015-05-28 18:18 ` Paul E. McKenney
2015-04-27 16:43 ` Jerome Glisse
2015-04-27 16:51 ` Christoph Lameter
2015-04-27 17:21 ` Jerome Glisse
2015-04-27 19:26 ` Christoph Lameter
2015-04-27 19:35 ` Rik van Riel
2015-04-27 20:52 ` Jerome Glisse
2015-04-28 14:18 ` Christoph Lameter
2015-04-28 17:20 ` Jerome Glisse
2015-04-27 16:15 ` Paul E. McKenney
2015-04-27 16:31 ` Christoph Lameter
2015-04-24 23:45 ` Benjamin Herrenschmidt
2015-04-23 18:52 ` Paul E. McKenney
2015-04-24 14:30 ` Christoph Lameter
2015-04-24 14:54 ` Paul E. McKenney
2015-04-24 15:49 ` Christoph Lameter
2015-04-24 16:06 ` Rik van Riel
2015-04-25 11:49 ` Paul E. McKenney
2015-04-24 16:00 ` Jerome Glisse
2015-04-24 16:08 ` Rik van Riel
2015-04-23 17:28 ` Rik van Riel
2015-04-23 2:27 ` Benjamin Herrenschmidt
2015-04-23 14:20 ` Christoph Lameter
2015-04-23 16:22 ` Jerome Glisse
2015-04-24 18:41 ` Oded Gabbay
2015-04-23 19:00 ` Paul E. McKenney
2015-04-22 15:20 ` Christoph Lameter
2015-04-25 2:32 ` Rik van Riel
2015-04-25 3:32 ` Benjamin Herrenschmidt
2015-04-25 11:55 ` Paul E. McKenney
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.11.1504221105130.24979@gentwo.org \
--to=cl@linux.com \
--cc=aarcange@redhat.com \
--cc=airlied@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=cabuschardt@nvidia.com \
--cc=ggerfin@nvidia.com \
--cc=j.glisse@gmail.com \
--cc=jglisse@redhat.com \
--cc=jmckenna@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhairgrove@nvidia.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=riel@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox