All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: torvalds@linux-foundation.org, roland@kernel.org,
	mingo@kernel.org, tglx@linutronix.de, kosaki.motohiro@gmail.com,
	penberg@kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-rdma@vger.kernel.org,
	Mike Marciniszyn <infinipath@intel.com>
Subject: Re: [PATCH] mm: Revert pinned_vm braindamage
Date: Mon, 17 Jun 2013 11:45:30 +0200	[thread overview]
Message-ID: <20130617094530.GO3204@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20130613140632.15982af2ebc443b24bfff86a@linux-foundation.org>

On Thu, Jun 13, 2013 at 02:06:32PM -0700, Andrew Morton wrote:
> Let's try to get this wrapped up?
> 
> On Thu, 6 Jun 2013 14:43:51 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > 
> > Patch bc3e53f682 ("mm: distinguish between mlocked and pinned pages")
> > broke RLIMIT_MEMLOCK.
> 
> I rather like what bc3e53f682 did, actually.  RLIMIT_MEMLOCK limits the
> amount of memory you can mlock().  Nice and simple.
> 
> This pinning thing which infiniband/perf are doing is conceptually
> different and if we care at all, perhaps we should be looking at adding
> RLIMIT_PINNED.

We could do that; but I really don't like doing it for the reasons I
outlined previously. It gives the user another knob to twiddle which is
pretty much the same as one he already has just slightly different.

Like said, I see RLIMIT_MEMLOCK to mean the amount of pages the user can
exempt from paging; since that is what the VM cares about most.

> > Before that patch: mm_struct::locked_vm < RLIMIT_MEMLOCK; after that
> > patch we have: mm_struct::locked_vm < RLIMIT_MEMLOCK &&
> > mm_struct::pinned_vm < RLIMIT_MEMLOCK.
> 
> But this is a policy decision which was implemented in perf_mmap() and
> perf can alter that decision.  How bad would it be if perf just ignored
> RLIMIT_MEMLOCK?

Then it could pin all memory -- seems like something bad.

> drivers/infiniband/hw/qib/qib_user_pages.c has issues, btw.  It
> compares the amount-to-be-pinned with rlimit(RLIMIT_MEMLOCK), but
> forgets to also look at current->mm->pinned_vm.  Duh.
> 
> It also does the pinned accounting in __qib_get_user_pages() but in
> __qib_release_user_pages(), the caller is supposed to do it, which is
> rather awkward.
> 
> 
> Longer-term I don't think that inifinband or perf should be dinking
> around with rlimit(RLIMIT_MEMLOCK) or ->pinned_vm.  Those policy
> decisions should be hoisted into a core mm helper where we can do it
> uniformly (and more correctly than infiniband's attempt!).

Agreed, hence my VM_PINNED proposal that would lift most of that to the
core VM.

I just got really lost in the IB code :/

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: torvalds@linux-foundation.org, roland@kernel.org,
	mingo@kernel.org, tglx@linutronix.de, kosaki.motohiro@gmail.com,
	penberg@kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-rdma@vger.kernel.org,
	Mike Marciniszyn <infinipath@intel.com>
Subject: Re: [PATCH] mm: Revert pinned_vm braindamage
Date: Mon, 17 Jun 2013 11:45:30 +0200	[thread overview]
Message-ID: <20130617094530.GO3204@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20130613140632.15982af2ebc443b24bfff86a@linux-foundation.org>

On Thu, Jun 13, 2013 at 02:06:32PM -0700, Andrew Morton wrote:
> Let's try to get this wrapped up?
> 
> On Thu, 6 Jun 2013 14:43:51 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > 
> > Patch bc3e53f682 ("mm: distinguish between mlocked and pinned pages")
> > broke RLIMIT_MEMLOCK.
> 
> I rather like what bc3e53f682 did, actually.  RLIMIT_MEMLOCK limits the
> amount of memory you can mlock().  Nice and simple.
> 
> This pinning thing which infiniband/perf are doing is conceptually
> different and if we care at all, perhaps we should be looking at adding
> RLIMIT_PINNED.

We could do that; but I really don't like doing it for the reasons I
outlined previously. It gives the user another knob to twiddle which is
pretty much the same as one he already has just slightly different.

Like said, I see RLIMIT_MEMLOCK to mean the amount of pages the user can
exempt from paging; since that is what the VM cares about most.

> > Before that patch: mm_struct::locked_vm < RLIMIT_MEMLOCK; after that
> > patch we have: mm_struct::locked_vm < RLIMIT_MEMLOCK &&
> > mm_struct::pinned_vm < RLIMIT_MEMLOCK.
> 
> But this is a policy decision which was implemented in perf_mmap() and
> perf can alter that decision.  How bad would it be if perf just ignored
> RLIMIT_MEMLOCK?

Then it could pin all memory -- seems like something bad.

> drivers/infiniband/hw/qib/qib_user_pages.c has issues, btw.  It
> compares the amount-to-be-pinned with rlimit(RLIMIT_MEMLOCK), but
> forgets to also look at current->mm->pinned_vm.  Duh.
> 
> It also does the pinned accounting in __qib_get_user_pages() but in
> __qib_release_user_pages(), the caller is supposed to do it, which is
> rather awkward.
> 
> 
> Longer-term I don't think that inifinband or perf should be dinking
> around with rlimit(RLIMIT_MEMLOCK) or ->pinned_vm.  Those policy
> decisions should be hoisted into a core mm helper where we can do it
> uniformly (and more correctly than infiniband's attempt!).

Agreed, hence my VM_PINNED proposal that would lift most of that to the
core VM.

I just got really lost in the IB code :/

  reply	other threads:[~2013-06-17  9:45 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-06 12:43 [PATCH] mm: Revert pinned_vm braindamage Peter Zijlstra
2013-06-06 12:43 ` Peter Zijlstra
2013-06-06 18:46 ` Christoph Lameter
2013-06-06 18:46   ` Christoph Lameter
2013-06-07 11:03   ` Peter Zijlstra
2013-06-07 11:03     ` Peter Zijlstra
     [not found]     ` <20130607110344.GA27176-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
2013-06-07 14:52       ` Christoph Lameter
2013-06-07 14:52         ` Christoph Lameter
2013-06-07 14:52         ` Christoph Lameter
2013-06-17 11:08         ` Peter Zijlstra
2013-06-17 11:08           ` Peter Zijlstra
2013-06-17 18:36           ` Christoph Lameter
2013-06-17 18:36             ` Christoph Lameter
     [not found]             ` <0000013f536c60ee-9a1ca9da-b798-416a-a32e-c896813d3bac-000000-p/GC64/jrecnJqMo6gzdpkEOCMrvLtNR@public.gmane.org>
2013-06-20 11:49               ` Ingo Molnar
2013-06-20 11:49                 ` Ingo Molnar
2013-06-20 11:49                 ` Ingo Molnar
2013-06-20 14:48                 ` Christoph Lameter
2013-06-20 14:48                   ` Christoph Lameter
     [not found]                   ` <0000013f620f4699-f484f28e-3d12-4560-adfe-3b00af995fd9-000000-p/GC64/jrecnJqMo6gzdpkEOCMrvLtNR@public.gmane.org>
2013-06-21  6:25                     ` Roland Dreier
2013-06-21  6:25                       ` Roland Dreier
2013-06-21  6:25                       ` Roland Dreier
2013-06-21 14:44                       ` Christoph Lameter
2013-06-21 14:44                         ` Christoph Lameter
2013-06-13 21:06 ` Andrew Morton
2013-06-13 21:06   ` Andrew Morton
2013-06-17  9:45   ` Peter Zijlstra [this message]
2013-06-17  9:45     ` Peter Zijlstra
     [not found]   ` <20130613140632.15982af2ebc443b24bfff86a-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2013-06-17 12:28     ` Thomas Gleixner
2013-06-17 12:28       ` Thomas Gleixner
2013-06-17 12:28       ` Thomas Gleixner
2013-06-20 11:34       ` Ingo Molnar
2013-06-20 11:34         ` Ingo Molnar

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=20130617094530.GO3204@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=infinipath@intel.com \
    --cc=kosaki.motohiro@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=penberg@kernel.org \
    --cc=roland@kernel.org \
    --cc=tglx@linutronix.de \
    --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 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.