All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Jerome Glisse <j.glisse@gmail.com>,
	lsf-pc@lists.linux-foundation.org,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [LSF/MM ATTEND] HMM (heterogeneous memory manager) and GPU
Date: Thu, 25 Feb 2016 14:49:33 +0100	[thread overview]
Message-ID: <20160225134933.GD22747@8bytes.org> (raw)
In-Reply-To: <1454460057.4788.117.camel@infradead.org>

Hey,

On Wed, Feb 03, 2016 at 12:40:57AM +0000, David Woodhouse wrote:
> There are a few related issues here around Shared Virtual Memory, and
> lifetime management of the associated MM, and the proposal discussed at
> the Kernel Summit for "off-CPU tasks".
> 
> I've hit a situation with the Intel SVM code in 4.4 where the device
> driver binds a PASID, and also has mmap() functionality on the same
> file descriptor that the PASID is associated with.
> 
> So on process exit, the MM doesn't die because the PASID binding still
> exists. The VMA of the mmap doesn't die because the MM still exists. So
> the underlying file remains open because the VMA still exists. And the
> PASID binding thus doesn't die because the file is still open.
> 
> I've posted a patchA1 which moves us closer to the amd_iommu_v2 model,
> although I'm still *strongly* resisting the temptation to call out into
> device driver code from the mmu_notifier's release callback.
> 
> I would like to attend LSF/MM this year so we can continue to work on
> those issues a?? now that we actually have some hardware in the field and
> a better idea of how we can build a unified access model for SVM across
> the different IOMMU types.

That sounds very interesting and I'd like to participate in this
discussion. Unfortunatly I can't make it to the mm-sumit this year, so I
didn't even apply for an invitation.

But if this gets discussed there I am interested in the outcome. I still
have a prototype for the off-cpu task concept on my list of thing to
implement. The problem is that I can't really test any changes I make
because I don't have SVM hardware and on the AMD side the user-space
part needed for testing only runs on Ubuntu with some AMD provided
kernel :(


	Joerg

--
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:[~2016-02-25 13:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28 17:55 [LSF/MM ATTEND] HMM (heterogeneous memory manager) and GPU Jerome Glisse
2016-01-29  9:50 ` Kirill A. Shutemov
2016-01-29 13:35   ` Jerome Glisse
2016-02-01 15:46 ` Aneesh Kumar K.V
2016-02-02 23:03   ` Jerome Glisse
2016-02-03  0:40 ` David Woodhouse
2016-02-03  8:13   ` Oded Gabbay
2016-02-03  8:40     ` David Woodhouse
2016-02-03  9:21       ` Oded Gabbay
2016-02-03 10:15         ` David Woodhouse
2016-02-03 11:01           ` Oded Gabbay
2016-02-03 11:07             ` Oded Gabbay
2016-02-03 11:35               ` David Woodhouse
2016-02-03 11:41                 ` David Woodhouse
2016-02-03 11:41                 ` Oded Gabbay
2016-02-03 12:22                   ` David Woodhouse
2016-02-25 13:49   ` Joerg Roedel [this message]

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=20160225134933.GD22747@8bytes.org \
    --to=joro@8bytes.org \
    --cc=dwmw2@infradead.org \
    --cc=j.glisse@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    /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.