From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jerome Glisse <j.glisse@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-mm <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Mel Gorman <mgorman@suse.de>, "H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linda Wang <lwang@redhat.com>, Kevin E Martin <kem@redhat.com>,
Jerome Glisse <jglisse@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Johannes Weiner <jweiner@redhat.com>,
Larry Woodman <lwoodman@redhat.com>,
Rik van Riel <riel@redhat.com>, Dave Airlie <airlied@redhat.com>,
Jeff Law <law@redhat.com>, Brendan Conoboy <blc@redhat.com>,
Joe Donohue <jdonohue@redhat.com>,
Duncan Poole <dpoole@nvidia.com>,
Sherry Cheung <SCheung@nvidia.com>,
Subhash
Subject: Re: [RFC] Heterogeneous memory management (mirror process address space on a device mmu).
Date: Wed, 07 May 2014 17:18:36 +1000 [thread overview]
Message-ID: <1399447116.4161.36.camel@pasglop> (raw)
In-Reply-To: <CA+55aFweCGWQMSxP09MJMhJ0XySZqvw=QaoUWwsWU4KaqDgOhw@mail.gmail.com>
On Tue, 2014-05-06 at 09:32 -0700, Linus Torvalds wrote:
> and what I think a GPU flush has to do is to do the actual flushes
> when asked to (because that's what it will need to do to work with a
> real TLB eventually), but if there's some crazy asynchronous
> acknowledge thing from hardware, it's possible to perhaps wait for
> that in the final phase (*before* we free the pages we gathered).
Hrm, difficult. We have some pretty strong assumptions that
ptep_clear_flush() is fully synchronous as far as I can tell... ie, your
trick would work for the unmap case but everything else is still
problematic.
Ben.
--
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:[~2014-05-07 7:18 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 13:51 [RFC] Heterogeneous memory management (mirror process address space on a device mmu) j.glisse
2014-05-02 13:52 ` [PATCH 01/11] mm: differentiate unmap for vmscan from other unmap j.glisse
2014-05-02 13:52 ` [PATCH 02/11] mmu_notifier: add action information to address invalidation j.glisse
2014-05-02 13:52 ` [PATCH 03/11] mmu_notifier: pass through vma to invalidate_range and invalidate_page j.glisse
2014-05-02 13:52 ` [PATCH 04/11] interval_tree: helper to find previous item of a node in rb interval tree j.glisse
2014-05-02 13:52 ` [PATCH 05/11] mm/memcg: support accounting null page and transfering null charge to new page j.glisse
2014-05-02 13:52 ` [PATCH 06/11] hmm: heterogeneous memory management j.glisse
2014-05-02 13:52 ` [PATCH 07/11] hmm: support moving anonymous page to remote memory j.glisse
2014-05-02 13:52 ` [PATCH 08/11] hmm: support for migrate file backed pages " j.glisse
2014-05-02 13:52 ` [PATCH 09/11] fs/ext4: add support for hmm migration to remote memory of pagecache j.glisse
2014-05-02 13:52 ` [PATCH 10/11] hmm/dummy: dummy driver to showcase the hmm api j.glisse
2014-05-02 13:52 ` [PATCH 11/11] hmm/dummy_driver: add support for fake remote memory using pages j.glisse
2014-05-06 10:29 ` [RFC] Heterogeneous memory management (mirror process address space on a device mmu) Peter Zijlstra
2014-05-06 14:57 ` Linus Torvalds
2014-05-06 15:00 ` Jerome Glisse
2014-05-06 15:18 ` Linus Torvalds
2014-05-06 15:33 ` Jerome Glisse
2014-05-06 15:42 ` Rik van Riel
2014-05-06 15:47 ` Linus Torvalds
2014-05-06 16:18 ` Jerome Glisse
2014-05-06 16:32 ` Linus Torvalds
2014-05-06 16:49 ` Jerome Glisse
2014-05-06 17:28 ` Jerome Glisse
2014-05-06 17:43 ` Linus Torvalds
2014-05-06 18:13 ` Jerome Glisse
2014-05-06 18:22 ` Linus Torvalds
2014-05-06 18:38 ` Jerome Glisse
2014-05-07 7:18 ` Benjamin Herrenschmidt [this message]
2014-05-07 7:14 ` Benjamin Herrenschmidt
2014-05-07 12:39 ` Jerome Glisse
2014-05-09 1:26 ` Jerome Glisse
2014-05-10 4:28 ` Benjamin Herrenschmidt
2014-05-11 0:48 ` Jerome Glisse
2014-05-06 16:30 ` Rik van Riel
2014-05-06 16:34 ` Linus Torvalds
2014-05-06 16:47 ` Rik van Riel
2014-05-06 16:54 ` Jerome Glisse
2014-05-06 18:02 ` H. Peter Anvin
2014-05-06 18:26 ` Jerome Glisse
2014-05-06 22:44 ` David Airlie
2014-05-07 2:33 ` Davidlohr Bueso
2014-05-07 13:00 ` Peter Zijlstra
2014-05-07 17:34 ` Davidlohr Bueso
2014-05-07 16:21 ` Linus Torvalds
2014-05-08 16:47 ` sagi grimberg
2014-05-08 17:56 ` Jerome Glisse
2014-05-09 1:42 ` Davidlohr Bueso
2014-05-09 1:45 ` Jerome Glisse
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=1399447116.4161.36.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=SCheung@nvidia.com \
--cc=aarcange@redhat.com \
--cc=airlied@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=blc@redhat.com \
--cc=dpoole@nvidia.com \
--cc=hpa@zytor.com \
--cc=j.glisse@gmail.com \
--cc=jdonohue@redhat.com \
--cc=jglisse@redhat.com \
--cc=jweiner@redhat.com \
--cc=kem@redhat.com \
--cc=law@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lwang@redhat.com \
--cc=lwoodman@redhat.com \
--cc=mgorman@suse.de \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=torvalds@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 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).