All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Holt <holt@sgi.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Robin Holt <holt@sgi.com>, Cliff Wickman <cpw@sgi.com>,
	linux-mm@kvack.org, aarcange@redhat.com, mgorman@suse.de
Subject: Re: [PATCH] mm: export mmu notifier invalidates
Date: Thu, 14 Feb 2013 16:25:24 -0600	[thread overview]
Message-ID: <20130214222524.GI3438@sgi.com> (raw)
In-Reply-To: <20130214135234.234a93f9.akpm@linux-foundation.org>

On Thu, Feb 14, 2013 at 01:52:34PM -0800, Andrew Morton wrote:
> On Thu, 14 Feb 2013 15:35:12 -0600
> Robin Holt <holt@sgi.com> wrote:
> 
> > I am open to suggestions.  Can you suggest existing kernel functionality
> > that allows one task to map another virtual address space into their
> > va space to allow userland-to-userland copies without system calls?
> > If there is functionality that has been introduced in the last couple
> > years, I could very well have missed it as I have been fairly heads-down
> > on other things for some time.
> 
> That's conceptually very similar to mm/process_vm_access.c. 
> process_vm_readv/writev do kernel-based copying rather than a direct
> mmap.

I will go look at those now.  I am not familiar with them as they went
in during my "dark period" where I was working on system controller
functionality and not paying attention to kernel activity.

> 
> > > To what extent is all this specific to SGI hardware characteristics?
> > 
> > SGI's hardware allows two things, a vastly larger virtual address space
> > and the ability to access memory in other system images on the same numa
> > fabric which are beyond the processsors physical addressing capabilities.
> > 
> > I am fairly sure Cray has taken an older version of XPMEM and stripped
> > out a bunch of SGI specific bits and implemented it on their hardware.
> > 
> > > > The above, of course, is an oversimplification, but should give you and
> > > > idea of the big picture design goals.
> > > >
> > > > Does any of this make sense?  Do you see areas where you think we should
> > > > extend regular mm functionality to include these functions?
> > > > 
> > > > How would you like me to proceed?
> > > 
> > > I'm obviously on first base here, but overall approach:
> > > 
> > > - Is the top-level feature useful to general Linux users?  Perhaps
> > >   after suitable generalisations (aka dumbing down :))
> > 
> > I am not sure how useful it is.  I know IBM has tried in the past to
> > get a similar feature introduced.  I believe they settled on a ptrace
> > extension to do direct user-to-user copies from within the kernel.
> 
> process_vm_readv/writev is from Christopher Yeoh@IBM.
> 
> > > - Even if the answer to that is "no", should we maintain the feature
> > >   in-tree rather than out-of-tree?
> > 
> > Not sure on the second one, but I believe Linus' objection is security and
> > I can certainly understand that.  Right now, SGI's xpmem implementation
> > enforces that all jobs in the task need to have the same UID.  There is
> > no exception for root or and administrator.
> 
> I'd have thought that the security processing of a direct map would be
> identical to those in process_vm_readv/writev?
> 
> If we were to add a general map-this-into-that facility which is
> available to and runs adequately on our typical machines, I assume your
> systems would need some SGI-specific augmentation?

Yes, for the extended virtual and physical address space and for the
weird page sizes.

Thanks,
Robin

--
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:[~2013-02-14 22:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12 21:35 [PATCH] mm: export mmu notifier invalidates Cliff Wickman
2013-02-12 21:57 ` Andrew Morton
2013-02-13 15:03   ` Robin Holt
2013-02-13 20:11     ` Andrew Morton
2013-02-13 21:03       ` Robin Holt
2013-02-14 21:08         ` Andrew Morton
2013-02-14 21:35           ` Robin Holt
2013-02-14 21:52             ` Andrew Morton
2013-02-14 22:25               ` Robin Holt [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-01-04 15:41 Cliff Wickman
2013-01-04 21:35 ` Christoph Hellwig
2013-01-04 22:09   ` Cliff Wickman
2013-01-07 14:14 ` Mel Gorman
2013-01-07 15:35   ` Andrea Arcangeli

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=20130214222524.GI3438@sgi.com \
    --to=holt@sgi.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=cpw@sgi.com \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    /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.