All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Gleb Natapov <gleb@redhat.com>
Cc: "Roland Dreier" <rdreier@cisco.com>,
	"Håkon Bugge" <Haakon.Bugge@Sun.COM>,
	"Jason Gunthorpe" <jgunthorpe@obsidianresearch.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Eric B Munson" <ebmunson@us.ibm.com>,
	linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
	rolandd@cisco.com, pavel@ucw.cz, mingo@elte.hu,
	jsquyres@cisco.com
Subject: Re: [PATCH] ummunotify: Userspace support for MMU notifications
Date: Thu, 15 Apr 2010 15:48:42 +0200	[thread overview]
Message-ID: <1271339322.1674.16.camel@laptop> (raw)
In-Reply-To: <20100414085228.GL23554@redhat.com>

On Wed, 2010-04-14 at 11:52 +0300, Gleb Natapov wrote:
> On Tue, Apr 13, 2010 at 08:02:54PM +0200, Peter Zijlstra wrote:
> > On Tue, 2010-04-13 at 10:57 -0700, Roland Dreier wrote:
> > > Are those system calls the only possible way that virtual to physical
> > > mappings can change?  Can't page migration or something like that
> > > potentially affect things?  And even if you did have hooks into every
> > > system call that mattered (keep in mind that relying on glibc is not
> > > enough, since an MPI application may not use glibc) would decoding them
> > > and figuring out what happened really be preferable to a single event
> > > type that tells you exactly what address range was affected? 
> > 
> > Yeah, virtual<->physical maps can change through swapping, page
> > migration, memory compaction, huge-page aggregation (the latter two not
> > yet being upstream).
> > 
> > Even mlock() doesn't pin virtual<->physical maps.
> Pages registered for RDMA are GUPed so no method above should touch
> them. Fork+cow or unmap/map on the other hand can change
> virtual<->physical maps. GUPed pages are still GUPed, but they are no
> longer mapped into process' virtual address space. MPI copes with
> Fork+cow by marking registered memory as MADV_DONTFORK.

Sure, holding a page-ref will pin the physical page, but that is not
something userspace usually has means to.

  reply	other threads:[~2010-04-15 13:48 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-12  6:22 [PATCH] ummunotify: Userspace support for MMU notifications Eric B Munson
2010-04-12  6:22 ` Eric B Munson
2010-04-12 23:03 ` Andrew Morton
     [not found]   ` <20100412160359.1d9074dc.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2010-04-12 23:59     ` Jason Gunthorpe
2010-04-12 23:59       ` Jason Gunthorpe
     [not found]       ` <20100412235937.GF15629-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2010-04-13  8:29         ` Håkon Bugge
2010-04-13  8:29           ` Håkon Bugge
     [not found]           ` <3251DDDA-D705-4B1E-9595-9C24709EF146-U0mLk4xYmo8@public.gmane.org>
2010-04-13 17:57             ` Roland Dreier
2010-04-13 17:57               ` Roland Dreier
     [not found]               ` <adahbnfme0j.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-04-13 18:02                 ` Peter Zijlstra
2010-04-13 18:02                   ` Peter Zijlstra
2010-04-14  5:18                   ` Håkon Bugge
2010-04-14  5:18                     ` Håkon Bugge
2010-04-14  8:52                   ` Gleb Natapov
2010-04-14  8:52                     ` Gleb Natapov
2010-04-15 13:48                     ` Peter Zijlstra [this message]
2010-04-14  9:06                 ` Gleb Natapov
2010-04-14  9:06                   ` Gleb Natapov
     [not found]                   ` <20100414090623.GM23554-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-04-14 14:36                     ` Jeff Squyres
2010-04-14 14:36                       ` Jeff Squyres
2010-04-17 17:41     ` Eric B Munson
2010-04-17 17:41       ` Eric B Munson
     [not found] ` <1271053337-7121-1-git-send-email-ebmunson-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-04-12 20:20   ` Pavel Machek
2010-04-12 20:20     ` Pavel Machek
2010-04-14 16:43   ` [PATCH] ummunotify: fix umn-test build Randy Dunlap
2010-04-14 16:43     ` Randy Dunlap
     [not found]     ` <20100414094341.ba69842d.randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2010-04-17 17:44       ` Eric B Munson
2010-04-17 17:44         ` Eric B Munson
     [not found]         ` <20100417174404.GB3579-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-04-18 14:38           ` Roland Dreier
2010-04-18 14:38             ` Roland Dreier

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=1271339322.1674.16.camel@laptop \
    --to=peterz@infradead.org \
    --cc=Haakon.Bugge@Sun.COM \
    --cc=akpm@linux-foundation.org \
    --cc=ebmunson@us.ibm.com \
    --cc=gleb@redhat.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=jsquyres@cisco.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pavel@ucw.cz \
    --cc=rdreier@cisco.com \
    --cc=rolandd@cisco.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.