From: Robin Holt <holt@sgi.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andrea Arcangeli <andrea@qumranet.com>, Robin Holt <holt@sgi.com>,
Avi Kivity <avi@qumranet.com>, Izik Eidus <izike@qumranet.com>,
kvm-devel@lists.sourceforge.net,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
steiner@sgi.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, daniel.blueman@quadrics.com
Subject: Re: Extending mmu_notifiers to handle __xip_unmap in a sleepable context?
Date: Fri, 1 Feb 2008 06:10:25 -0600 [thread overview]
Message-ID: <20080201121024.GN26420@sgi.com> (raw)
In-Reply-To: <20080201115841.GM26420@sgi.com>
Argh,
Here is the correct one. Sorry
On Fri, Feb 01, 2008 at 05:58:41AM -0600, Robin Holt wrote:
> With this set of patches, I think we have enough to get xpmem working
> with most types of mappings. In the past, we operated without any of
> these callouts by significantly restricting why types of mappings could
> remotely fault and what types of operations the user could do. With
> this set, I am certain we can continue to meet the above assumptions.
>
> That said, I would like to discuss __xip_unmap in more detail.
>
> Currently, it is calling mmu_notifier _begin and _end under the
> i_mmap_lock. I _THINK_ the following will make it so we could support
> __xip_unmap (although I don't recall ever seeing that done on ia64 and
> don't even know what the circumstances are for its use).
Index: mmu_notifiers-cl-v5/mm/filemap_xip.c
===================================================================
--- mmu_notifiers-cl-v5.orig/mm/filemap_xip.c 2008-02-01 05:38:32.000000000 -0600
+++ mmu_notifiers-cl-v5/mm/filemap_xip.c 2008-02-01 06:09:09.000000000 -0600
@@ -184,6 +184,10 @@ __xip_unmap (struct address_space * mapp
if (!page)
return;
+ if (unlikely(PageExternalRmap(page))) {
+ mmu_rmap_notifier(invalidate_page, page);
+ ClearPageExternalRmap(page);
+ }
spin_lock(&mapping->i_mmap_lock);
vma_prio_tree_foreach(vma, &iter, &mapping->i_mmap, pgoff, pgoff) {
mm = vma->vm_mm;
WARNING: multiple messages have this Message-ID (diff)
From: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
To: Christoph Lameter <clameter-sJ/iWh9BUns@public.gmane.org>
Cc: Andrea Arcangeli <andrea-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
Peter Zijlstra
<a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
steiner-sJ/iWh9BUns@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
daniel.blueman-xqY44rlHlBpWk0Htik3J/w@public.gmane.org,
Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
Subject: Re: Extending mmu_notifiers to handle __xip_unmap in a sleepable context?
Date: Fri, 1 Feb 2008 06:10:25 -0600 [thread overview]
Message-ID: <20080201121024.GN26420@sgi.com> (raw)
In-Reply-To: <20080201115841.GM26420-sJ/iWh9BUns@public.gmane.org>
Argh,
Here is the correct one. Sorry
On Fri, Feb 01, 2008 at 05:58:41AM -0600, Robin Holt wrote:
> With this set of patches, I think we have enough to get xpmem working
> with most types of mappings. In the past, we operated without any of
> these callouts by significantly restricting why types of mappings could
> remotely fault and what types of operations the user could do. With
> this set, I am certain we can continue to meet the above assumptions.
>
> That said, I would like to discuss __xip_unmap in more detail.
>
> Currently, it is calling mmu_notifier _begin and _end under the
> i_mmap_lock. I _THINK_ the following will make it so we could support
> __xip_unmap (although I don't recall ever seeing that done on ia64 and
> don't even know what the circumstances are for its use).
Index: mmu_notifiers-cl-v5/mm/filemap_xip.c
===================================================================
--- mmu_notifiers-cl-v5.orig/mm/filemap_xip.c 2008-02-01 05:38:32.000000000 -0600
+++ mmu_notifiers-cl-v5/mm/filemap_xip.c 2008-02-01 06:09:09.000000000 -0600
@@ -184,6 +184,10 @@ __xip_unmap (struct address_space * mapp
if (!page)
return;
+ if (unlikely(PageExternalRmap(page))) {
+ mmu_rmap_notifier(invalidate_page, page);
+ ClearPageExternalRmap(page);
+ }
spin_lock(&mapping->i_mmap_lock);
vma_prio_tree_foreach(vma, &iter, &mapping->i_mmap, pgoff, pgoff) {
mm = vma->vm_mm;
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
WARNING: multiple messages have this Message-ID (diff)
From: Robin Holt <holt@sgi.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andrea Arcangeli <andrea@qumranet.com>, Robin Holt <holt@sgi.com>,
Avi Kivity <avi@qumranet.com>, Izik Eidus <izike@qumranet.com>,
kvm-devel@lists.sourceforge.net,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
steiner@sgi.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, daniel.blueman@quadrics.com
Subject: Re: Extending mmu_notifiers to handle __xip_unmap in a sleepable context?
Date: Fri, 1 Feb 2008 06:10:25 -0600 [thread overview]
Message-ID: <20080201121024.GN26420@sgi.com> (raw)
In-Reply-To: <20080201115841.GM26420@sgi.com>
Argh,
Here is the correct one. Sorry
On Fri, Feb 01, 2008 at 05:58:41AM -0600, Robin Holt wrote:
> With this set of patches, I think we have enough to get xpmem working
> with most types of mappings. In the past, we operated without any of
> these callouts by significantly restricting why types of mappings could
> remotely fault and what types of operations the user could do. With
> this set, I am certain we can continue to meet the above assumptions.
>
> That said, I would like to discuss __xip_unmap in more detail.
>
> Currently, it is calling mmu_notifier _begin and _end under the
> i_mmap_lock. I _THINK_ the following will make it so we could support
> __xip_unmap (although I don't recall ever seeing that done on ia64 and
> don't even know what the circumstances are for its use).
Index: mmu_notifiers-cl-v5/mm/filemap_xip.c
===================================================================
--- mmu_notifiers-cl-v5.orig/mm/filemap_xip.c 2008-02-01 05:38:32.000000000 -0600
+++ mmu_notifiers-cl-v5/mm/filemap_xip.c 2008-02-01 06:09:09.000000000 -0600
@@ -184,6 +184,10 @@ __xip_unmap (struct address_space * mapp
if (!page)
return;
+ if (unlikely(PageExternalRmap(page))) {
+ mmu_rmap_notifier(invalidate_page, page);
+ ClearPageExternalRmap(page);
+ }
spin_lock(&mapping->i_mmap_lock);
vma_prio_tree_foreach(vma, &iter, &mapping->i_mmap, pgoff, pgoff) {
mm = vma->vm_mm;
--
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:[~2008-02-01 12:11 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-01 5:04 [patch 0/4] [RFC] EMMU Notifiers V5 Christoph Lameter
2008-02-01 5:04 ` Christoph Lameter
2008-02-01 5:04 ` [patch 1/4] mmu_notifier: Core code Christoph Lameter
2008-02-01 5:04 ` Christoph Lameter
2008-02-01 10:55 ` Robin Holt
2008-02-01 10:55 ` Robin Holt
2008-02-01 10:55 ` Robin Holt
2008-02-01 11:04 ` Robin Holt
2008-02-01 11:04 ` Robin Holt
2008-02-01 19:14 ` Christoph Lameter
2008-02-01 19:14 ` Christoph Lameter
2008-02-01 19:14 ` Christoph Lameter
2008-02-01 5:04 ` [patch 2/4] mmu_notifier: Callbacks to invalidate address ranges Christoph Lameter
2008-02-01 5:04 ` Christoph Lameter
2008-02-01 10:49 ` Robin Holt
2008-02-01 10:49 ` Robin Holt
2008-02-01 10:49 ` Robin Holt
2008-02-01 19:14 ` Christoph Lameter
2008-02-01 19:14 ` Christoph Lameter
2008-02-01 19:14 ` Christoph Lameter
2008-02-01 22:09 ` Robin Holt
2008-02-01 22:09 ` Robin Holt
2008-02-01 23:19 ` Christoph Lameter
2008-02-01 23:19 ` Christoph Lameter
2008-02-01 23:35 ` Robin Holt
2008-02-01 23:35 ` Robin Holt
2008-02-01 23:35 ` Robin Holt
2008-02-02 0:05 ` Christoph Lameter
2008-02-02 0:05 ` Christoph Lameter
2008-02-02 0:05 ` Christoph Lameter
2008-02-02 0:21 ` Robin Holt
2008-02-02 0:21 ` Robin Holt
2008-02-02 0:21 ` Robin Holt
2008-02-02 0:38 ` Robin Holt
2008-02-02 0:38 ` Robin Holt
2008-02-02 0:38 ` Robin Holt
2008-02-03 2:23 ` Andrea Arcangeli
2008-02-03 2:23 ` Andrea Arcangeli
2008-02-03 2:23 ` Andrea Arcangeli
2008-02-01 5:04 ` [patch 3/4] mmu_notifier: invalidate_page callbacks Christoph Lameter
2008-02-01 5:04 ` Christoph Lameter
2008-02-01 5:04 ` [patch 4/4] mmu_notifier: Support for driverws with revers maps (f.e. for XPmem) Christoph Lameter
2008-02-01 5:04 ` Christoph Lameter
2008-02-01 11:58 ` Extending mmu_notifiers to handle __xip_unmap in a sleepable context? Robin Holt
2008-02-01 11:58 ` Robin Holt
2008-02-01 11:58 ` Robin Holt
2008-02-01 12:10 ` Robin Holt [this message]
2008-02-01 12:10 ` Robin Holt
2008-02-01 12:10 ` Robin Holt
2008-02-01 19:17 ` Christoph Lameter
2008-02-01 19:17 ` Christoph Lameter
2008-02-01 19:17 ` Christoph Lameter
2008-02-03 1:39 ` [patch 0/4] [RFC] EMMU Notifiers V5 Andrea Arcangeli
2008-02-03 1:39 ` Andrea Arcangeli
2008-02-03 13:41 ` Robin Holt
2008-02-03 13:41 ` Robin Holt
2008-02-03 13:41 ` Robin Holt
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=20080201121024.GN26420@sgi.com \
--to=holt@sgi.com \
--cc=a.p.zijlstra@chello.nl \
--cc=andrea@qumranet.com \
--cc=avi@qumranet.com \
--cc=clameter@sgi.com \
--cc=daniel.blueman@quadrics.com \
--cc=izike@qumranet.com \
--cc=kvm-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=steiner@sgi.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 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.