iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Jerome Glisse <j.glisse@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Joerg Roedel <jroedel@suse.de>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Rik van Riel <riel@redhat.com>,
	Jay.Cornwall@amd.com, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	John.Bridgman@amd.com, Hugh Dickins <hughd@google.com>,
	linux-kernel@vger.kernel.org, ben.sander@amd.com,
	linux-mm@kvack.org, Jerome Glisse <jglisse@redhat.com>,
	iommu@lists.linux-foundation.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	Mel Gorman <mgorman@suse.de>,
	David Woodhouse <dwmw2@infradead.org>,
	Johannes Weiner <jweiner@redhat.com>
Subject: Re: [PATCH 0/3 v3] mmu_notifier: Allow to manage CPU external TLBs
Date: Fri, 12 Sep 2014 15:28:37 -0400	[thread overview]
Message-ID: <20140912192837.GC5196@gmail.com> (raw)
In-Reply-To: <20140912121937.ebb3010d52abd4196e9341de@linux-foundation.org>

On Fri, Sep 12, 2014 at 12:19:37PM -0700, Andrew Morton wrote:
> On Fri, 12 Sep 2014 20:47:39 +0200 Joerg Roedel <jroedel@suse.de> wrote:
> 
> > thanks for your review, I tried to answer your questions below.
> 
> You'd be amazed how helpful that was ;)
> 
> > Fair enough, I hope I clarified a few things with my explanations
> > above. I will also update the description of the patch-set when I
> > re-send.
> 
> Sounds good, thanks.
> 
> 
> How does HMM play into all of this?  Would HMM make this patchset
> obsolete, or could HMM be evolved to do so?  

HMM should be consider as distinc from this. The hardware TLB we are talking
with this patchset can be flush by the CPU from inside an atomic context (ie
while holding cpu page table spinlock for instance).

HMM on the other hand deals with hardware that have there own page table
ie they do not necessarily walk the cpu page table. Flushing the TLB for this
kind of hardware means scheduling some job on the hardware and this can not
be done from kernel atomic context as this job might take a long time to
complete (imagine preempting thousand of threads on a gpu).

Still HMM can be use in a mixed environement where the IOMMUv2 is use for
memory that reside into system ram while HMM only handle memory that have
been migrated to the device memory.

So while HMM intend to provide more features than IOMMUv2 hardware allow,
it does not intend to replace it. On contrary hope is that both can work at
same time.

Cheers,
Jérôme

> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu

--
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:[~2014-09-12 19:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-09 15:43 [PATCH 0/3 v3] mmu_notifier: Allow to manage CPU external TLBs Joerg Roedel
2014-09-09 15:43 ` [PATCH 1/3] mmu_notifier: Add mmu_notifier_invalidate_range() Joerg Roedel
     [not found] ` <1410277434-3087-1-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-09-09 15:43   ` [PATCH 2/3] mmu_notifier: Call mmu_notifier_invalidate_range() from VMM Joerg Roedel
2014-09-09 15:43   ` [PATCH 3/3] mmu_notifier: Add the call-back for mmu_notifier_invalidate_range() Joerg Roedel
2014-09-10 22:01 ` [PATCH 0/3 v3] mmu_notifier: Allow to manage CPU external TLBs Andrew Morton
2014-09-11  0:02   ` Jerome Glisse
2014-09-12 18:39     ` Jerome Glisse
     [not found]     ` <20140911000211.GA4989-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-09-12 19:10       ` Andrew Morton
2014-09-12 19:21         ` Jerome Glisse
2014-09-12 19:27           ` Andrew Morton
     [not found]   ` <20140910150125.31a7495c7d0fe814b85fd514-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2014-09-12 18:47     ` Joerg Roedel
     [not found]       ` <20140912184739.GF2519-l3A5Bk7waGM@public.gmane.org>
2014-09-12 19:19         ` Andrew Morton
2014-09-12 19:28           ` Jerome Glisse [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=20140912192837.GC5196@gmail.com \
    --to=j.glisse@gmail.com \
    --cc=Jay.Cornwall@amd.com \
    --cc=John.Bridgman@amd.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ben.sander@amd.com \
    --cc=dwmw2@infradead.org \
    --cc=hughd@google.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jglisse@redhat.com \
    --cc=jroedel@suse.de \
    --cc=jweiner@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --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;
as well as URLs for NNTP newsgroup(s).