public inbox for trinity@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Christoph Lameter <cl@linux.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
	Vince Weaver <vincent.weaver@maine.edu>,
	linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	trinity@vger.kernel.org
Subject: Re: OOPS in perf_mmap_close()
Date: Thu, 23 May 2013 17:24:58 +0200	[thread overview]
Message-ID: <20130523152458.GD23650@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <0000013ed1b8d0cc-ad2bb878-51bd-430c-8159-629b23ed1b44-000000@email.amazonses.com>

On Thu, May 23, 2013 at 02:09:10PM +0000, Christoph Lameter wrote:
> On Thu, 23 May 2013, Peter Zijlstra wrote:
> 
> > Right it doesn't. I think the easiest solution for now is to not copy the VMA
> > on fork().
> 
> Right. Pinned pages are not inherited. If a page is unpinned then that is
> going to happen for all address spaces that reference the page.
> 
> > But I totally missed patch bc3e53f682d that introduced pinned_vm, AFAICT that
> > also wrecked some accounting. We should still account both against
> > RLIMIT_MEMLOCK.
> 
> The point of the patch was to unwreck accounting. Before the patch mlocked
> pages were counted twice which resulted in stramge VM scenarios where more
> pages were mlocked than memory available. Note that a pinned page may also
> be mlocked.
> 
> Simply adding the two will reintroduce the problems that were fixed by the
> patch.

The patch completely fails to explain how RLIMIT_LOCKED is supposed to
deal with pinned vs locked. Perf used to account its pages against
RLIMIT_LOCKED, with the patch it compares pinned against RLIMIT_LOCKED
but completely discards any possible locked pages.

IMO that's broken.

  reply	other threads:[~2013-05-23 15:24 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-22 19:35 OOPS in perf_mmap_close() Vince Weaver
2013-05-22 23:56 ` Vince Weaver
2013-05-23  3:48   ` Vince Weaver
2013-05-23  4:48     ` Al Viro
2013-05-23 10:41       ` Peter Zijlstra
2013-05-23 14:09         ` Christoph Lameter
2013-05-23 15:24           ` Peter Zijlstra [this message]
2013-05-23 16:12             ` Christoph Lameter
2013-05-23 16:39               ` Peter Zijlstra
2013-05-23 17:59                 ` Christoph Lameter
2013-05-23 19:24                   ` Peter Zijlstra
2013-05-24 14:01                   ` [RFC][PATCH] mm: Fix RLIMIT_MEMLOCK Peter Zijlstra
2013-05-24 15:40                     ` Christoph Lameter
2013-05-26  1:11                       ` KOSAKI Motohiro
2013-05-28 16:19                         ` Christoph Lameter
2013-05-27  6:48                       ` Peter Zijlstra
2013-05-28 16:37                         ` Christoph Lameter
2013-05-29  7:58                           ` [regression] " Ingo Molnar
2013-05-29 19:53                             ` KOSAKI Motohiro
2013-05-30  6:32                               ` Ingo Molnar
2013-05-30 20:42                                 ` KOSAKI Motohiro
2013-05-31  9:27                                   ` Ingo Molnar
2013-05-30 18:30                           ` Peter Zijlstra
2013-05-30 19:59                           ` Pekka Enberg
2013-05-30 21:00                     ` KOSAKI Motohiro
2013-05-23 12:52       ` OOPS in perf_mmap_close() Peter Zijlstra
2013-05-23 14:10         ` Vince Weaver
2013-05-23 15:26           ` Peter Zijlstra
2013-05-23 15:47             ` Vince Weaver
2013-05-23 23:40             ` Vince Weaver
2013-05-24  9:21               ` Peter Zijlstra
2013-05-28  8:55               ` Peter Zijlstra
2013-05-28 16:19                 ` Vince Weaver
2013-05-28 18:22                   ` Vince Weaver
2013-05-29  7:44                     ` Peter Zijlstra
2013-05-29 13:17                       ` Vince Weaver
2013-05-29 19:18                       ` Vince Weaver
2013-05-30  7:25                         ` Peter Zijlstra
2013-05-30 12:51                           ` Vince Weaver
2013-05-31 15:46                             ` Peter Zijlstra
2013-06-03 13:26                             ` Peter Zijlstra
2013-06-03 17:18                               ` Peter Zijlstra
2013-06-03 19:25                               ` Peter Zijlstra
2013-06-05 15:54                                 ` Vince Weaver
2013-06-05 16:54                                   ` Peter Zijlstra
2013-05-29  8:07                   ` 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=20130523152458.GD23650@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@ghostprotocols.net \
    --cc=cl@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=trinity@vger.kernel.org \
    --cc=vincent.weaver@maine.edu \
    --cc=viro@ZenIV.linux.org.uk \
    /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