linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Christoph Lameter <cl@linux.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>, Mel Gorman <mgorman@suse.de>,
	Roland Dreier <roland@kernel.org>,
	Sean Hefty <sean.hefty@intel.com>,
	Hal Rosenstock <hal.rosenstock@gmail.com>,
	Mike Marciniszyn <infinipath@intel.com>
Subject: Re: [RFC][PATCH 0/5] VM_PINNED
Date: Tue, 27 May 2014 12:29:09 +0200	[thread overview]
Message-ID: <20140527102909.GO30445@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <CALYGNiO8FNKjtETQMRSqgiArjfQ9nRAALUg9GGdNYbpKru=Sjw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]

On Tue, May 27, 2014 at 12:49:08AM +0400, Konstantin Khlebnikov wrote:
> On Tue, May 27, 2014 at 12:32 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > Pretty much, that's adequate for all users I'm aware of and mirrors the
> > mlock semantics.
> 
> Ok, fine. Because get_user_pages is used sometimes for pinning pages
> from different mm.

Yeah, but that's fairly uncommon, and not something we do for very long
times afaik.

In fact I could only find:

  drivers/iommu/amd_iommu_v2.c

  fs/exec.c -- temporary use
  kernel/events/uprobes.c -- temporary use
  mm/ksm.c -- temporary use
  mm/process_vm_access.c -- temporary use

With exception of the iommu one (it wasn't immediately obvious and I
didn't want to stare at the iommu muck too long), they're all temporary,
we drop the page almost immediately again after doing some short work.

The things I care about for VM_PINNED are long term pins, like the IB
stuff, which sets up its RDMA buffers at the start of a program and
basically leaves them in place for the entire duration of said program.

Such pins will disrupt CMA, compaction and pretty much anything that
relies on the page blocks stuff.

> Another suggestion. VM_RESERVED is stronger than VM_LOCKED and extends
> its functionality.
> Maybe it's easier to add VM_DONTMIGRATE and use it together with VM_LOCKED.
> This will make accounting easier. No?

I prefer the PINNED name because the not being able to migrate is only
one of the desired effects of it, not the primary effect. We're really
looking to keep physical pages in place and preserve mappings.

The -rt people for example really want to avoid faults (even minor
faults), and DONTMIGRATE would still allow unmapping.

Maybe always setting VM_PINNED and VM_LOCKED together is easier, I
hadn't considered that. The first thing that came to mind is that that
might make the fork() semantics difficult, but maybe it works out.

And while we're on the subject, my patch preserves PINNED over fork()
but maybe we don't actually need that either.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2014-05-27 10:29 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-26 14:56 Peter Zijlstra
2014-05-26 14:56 ` [RFC][PATCH 1/5] mm: Introduce VM_PINNED and interfaces Peter Zijlstra
2014-05-29  1:48   ` Rik van Riel
2014-05-29  8:01     ` Peter Zijlstra
2014-05-26 14:56 ` [RFC][PATCH 2/5] mm,perf: Make use of VM_PINNED Peter Zijlstra
2014-05-26 14:56 ` [RFC][PATCH 3/5] mm,ib,umem: Use VM_PINNED Peter Zijlstra
2014-05-26 14:56 ` [RFC][PATCH 4/5] mm,ib,ipath: " Peter Zijlstra
2014-05-26 14:56 ` [RFC][PATCH 5/5] mm,ib,qib: " Peter Zijlstra
2014-05-26 20:19 ` [RFC][PATCH 0/5] VM_PINNED Konstantin Khlebnikov
2014-05-26 20:32   ` Peter Zijlstra
2014-05-26 20:49     ` Konstantin Khlebnikov
2014-05-27 10:29       ` Peter Zijlstra [this message]
2014-05-27 10:54         ` Peter Zijlstra
2014-05-27 11:11           ` Konstantin Khlebnikov
2014-05-27 11:50             ` Vlastimil Babka
2014-05-27 13:09               ` Peter Zijlstra
2014-05-27 13:05             ` Peter Zijlstra
2014-05-27 14:34         ` Christoph Lameter
2014-05-27 14:46           ` Peter Zijlstra
2014-05-27 15:14             ` Christoph Lameter
2014-05-27 15:31               ` Peter Zijlstra
2014-05-27 16:31                 ` Christoph Lameter
2014-05-27 16:43                   ` Peter Zijlstra
2014-05-27 16:56                     ` Christoph Lameter
2014-05-27 17:29                       ` Peter Zijlstra
2014-05-27 20:00                         ` Christoph Lameter
2014-05-28  6:14                           ` Peter Zijlstra
2014-08-01 10:16     ` Benjamin Herrenschmidt

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=20140527102909.GO30445@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=hal.rosenstock@gmail.com \
    --cc=hughd@google.com \
    --cc=infinipath@intel.com \
    --cc=koct9i@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=roland@kernel.org \
    --cc=sean.hefty@intel.com \
    --cc=tglx@linutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox