From: John Hubbard <jhubbard@nvidia.com>
To: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org
Cc: Jerome Glisse <jglisse@redhat.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>,
Serguei Sagalovitch <serguei.sagalovitch@amd.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Balbir Singh <bsingharora@gmail.com>,
Michael Repasy <mrepasy@nvidia.com>
Subject: [LSF/MM ATTEND] HMM, CDM and other infrastructure for device memory management
Date: Tue, 10 Jan 2017 20:22:43 -0800 [thread overview]
Message-ID: <alpine.LNX.2.20.1701101600280.38701@blueforge.nvidia.com> (raw)
Hi,
I would like to attend this topic that Jerome has proposed. Studying the
kernel is a deep personal interest in addition to my career focus, and it
would be a rare privilege to work directly with some of you to converge
on some nice, clean designs for the kernel and these "new"
(page-fault-capable) devices that we have now. Here's what I can bring to
the discussion:
a) An NVIDIA perspective on, and experience with, using the HMM patchset,
versions 1-15, at the device driver level. In addition to working on the
nvidia-uvm.ko driver (which handles CPU and GPU page faulting) since its
inception, I've also helped develop and maintain various facets of our GPU
device driver for Linux, for the last 9 years.
As a semi-relevant aside, our company is allocating engineering time,
including mine, for long-term kernel projects such as this one. We want to
participate in maintaining and improving the kernel. I find that highly
encouraging and I hope others do, too. Times really are changing.
b) Some thoughts about the dividing line between core kernel and drivers.
Our device drivers are starting to push the limits of what drivers should
really do (we are heading perhaps too deeply into memory management), and
of course I want to avoid going too far. For example, I've seen
recent comments on linux-mm that drivers shouldn't even take mmap_sem,
which is intriguing. We need to provide...something for that, though.
c) Some thoughts about dealing with both HMM and ATS in the same driver
(our devices have to support both--although, not at the same time).
--
For this discussion track, I'm especially interested in simultaneously
considering:
1. HMM (Jerome's Heterogeneous Memory Management patchset): this solves a
similar problem as ATS (Address Translation Services: unified CPU and
Device page tables), but without the need for specialized hardware. There
is a bit of overlap between the HMM and ATS+NUMA patchsets, as has been
discussed here before.
2. IBM's ATS+NUMA patchset.
3. Page-fault-capable devices in general.
thanks,
John Hubbard
--
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 reply other threads:[~2017-01-11 4:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-11 4:22 John Hubbard [this message]
2017-01-16 12:19 ` [LSF/MM ATTEND] HMM, CDM and other infrastructure for device memory management Anshuman Khandual
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.LNX.2.20.1701101600280.38701@blueforge.nvidia.com \
--to=jhubbard@nvidia.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=bsingharora@gmail.com \
--cc=jglisse@redhat.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mrepasy@nvidia.com \
--cc=serguei.sagalovitch@amd.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;
as well as URLs for NNTP newsgroup(s).