linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Christopher Yeoh <cyeoh@au1.ibm.com>
Cc: linux-mm@kvack.org, Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [Resend] Cross Memory Attach v3 [PATCH]
Date: Sun, 20 Mar 2011 18:55:32 -0700	[thread overview]
Message-ID: <20110320185532.08394018.akpm@linux-foundation.org> (raw)
In-Reply-To: <20110321122018.6306d067@lilo>

On Mon, 21 Mar 2011 12:20:18 +1030 Christopher Yeoh <cyeoh@au1.ibm.com> wrote:

> On Thu, 17 Mar 2011 12:54:27 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Thu, 17 Mar 2011 15:40:26 +1030
> > Christopher Yeoh <cyeoh@au1.ibm.com> wrote:
> > 
> > > > Thinking out loud: if we had a way in which a process can add and
> > > > remove a local anonymous page into pagecache then other processes
> > > > could access that page via mmap.  If both processes map the file
> > > > with a nonlinear vma they they can happily sit there flipping
> > > > pages into and out of the shared mmap at arbitrary file offsets.
> > > > The details might get hairy ;) We wouldn't want all the regular
> > > > mmap semantics of
> > > 
> > > Yea, its the complexity of trying to do it that way that eventually
> > > lead me to implementing it via a syscall and get_user_pages
> > > instead, trying to keep things as simple as possible.
> > 
> > The pagecache trick potentially gives zero-copy access, whereas the
> > proposed code is single-copy.  Although the expected benefits of that
> > may not be so great due to TLB manipulation overheads.
> > 
> > I worry that one day someone will come along and implement the
> > pagecache trick, then we're stuck with obsolete code which we have to
> > maintain for ever.
> 
> Perhaps I don't understand what you're saying correctly but I think that
> one problem with the zero copy page flipping approach is that there
> is no guarantee with the data that the MPI apps want to send 
> resides in a page or pages all by itself.

Well.  The applications could of course be changed.  But if the
applications are changeable then they could be changed to use
MAP_SHARED memory sharing and we wouldn't be having this discussion,
yes?

(Why can't the applications be changed to use existing shared memory
capabilities, btw?)

But yes, I'm assuming that it will be acceptable for the sending app to
expose some memory (up to PAGE_SIZE-1) below and above the actual
payload which is to be transferred.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-03-21  1:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-15  4:05 [Resend] Cross Memory Attach v3 [PATCH] Christopher Yeoh
2011-03-15 23:16 ` Andrew Morton
2011-03-17  5:10   ` Christopher Yeoh
2011-03-17 19:54     ` Andrew Morton
2011-03-21  1:50       ` Christopher Yeoh
2011-03-21  1:55         ` Andrew Morton [this message]
2011-03-21  2:15           ` Christopher Yeoh
2011-03-23  2:22           ` Christopher Yeoh
2011-03-23 22:50             ` Rusty Russell
2011-03-25 13:22               ` Christopher Yeoh
2011-04-12  0:48                 ` Christopher Yeoh

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=20110320185532.08394018.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=cyeoh@au1.ibm.com \
    --cc=linux-mm@kvack.org \
    --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).