From: Dave McCracken <dave.mccracken@oracle.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: herbert.van.den.bergh@oracle.com, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] include private data mappings in RLIMIT_DATA limit
Date: Tue, 10 Jul 2007 14:12:19 -0500 [thread overview]
Message-ID: <200707101412.19785.dave.mccracken@oracle.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0707101857310.20758@blonde.wat.veritas.com>
On Tuesday 10 July 2007, Hugh Dickins wrote:
> On Tue, 10 Jul 2007, Dave McCracken wrote:
> > Given that RLIMIT_DATA is pretty much meaningless in current kernels, I
> > would put forward the argument that this change is extremely unlikely to
> > break anything because no one is currently setting it to anything other
> > than unlimited. Adding this feature would give administrators another
> > tool, a way to control the private data size of a process without
> > restricting its ability to attach to large shared mappings.
>
> That may be a good argument (though "extremely unlikely to break"s
> have a nasty habit of biting). I'd still say that the contribution
> to Committed_AS is more appropriate and more useful here.
You may be right... I suppose everything will bite someone somewhere with a
sufficiently large user base.
As for whether Committed_AS is more appropriate, I'll have to defer to Herbert
on this one. He stated that RLIMIT_DATA no longer does what it was intended
to do, and offered a fix for it, and I agreed with him. I do believe his
patch does a reasonable approximation of the original intent of RLIMIT_DATA,
but I didn't delve into the actual intended use of it once it's fixed.
> > > That change to /proc/PID/status VmData:
> > > - data = mm->total_vm - mm->shared_vm - mm->stack_vm;
> > > + data = mm->total_vm - mm->shared_vm - mm->stack_vm - mm->exec_vm;
> > > looks plausible, but isn't exec_vm already counted as shared_vm,
> > > so now being doubly subtracted? Besides which, we wouldn't want
> > > to change those numbers again without consulting Albert.
> >
> > As I recall, this was added after Herbert discovered that exec_vm is not
> > counted as shared_vm. It's actually mapped as private/readonly.
>
> Mapped private readonly yes, but vm_stat_account() says
> if (file) {
> mm->shared_vm += pages;
> if ((flags & (VM_EXEC|VM_WRITE)) == VM_EXEC)
> mm->exec_vm += pages;
In that code shared_vm includes everything that's mmap()ed, including private
mappings. But if you look at Herbert's patch he has the following change:
if (file) {
- mm->shared_vm += pages;
+ if (flags & VM_SHARED)
+ mm->shared_vm += pages;
if ((flags & (VM_EXEC|VM_WRITE)) == VM_EXEC)
mm->exec_vm += pages;
This means that shared_vm now is truly only memory that's mapped VM_SHARED and
does not include VM_EXEC memory. That necessitates the separate subtraction
of exec_vm in the data calculations.
Dave McCracken
WARNING: multiple messages have this Message-ID (diff)
From: Dave McCracken <dave.mccracken@oracle.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: herbert.van.den.bergh@oracle.com, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] include private data mappings in RLIMIT_DATA limit
Date: Tue, 10 Jul 2007 14:12:19 -0500 [thread overview]
Message-ID: <200707101412.19785.dave.mccracken@oracle.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0707101857310.20758@blonde.wat.veritas.com>
On Tuesday 10 July 2007, Hugh Dickins wrote:
> On Tue, 10 Jul 2007, Dave McCracken wrote:
> > Given that RLIMIT_DATA is pretty much meaningless in current kernels, I
> > would put forward the argument that this change is extremely unlikely to
> > break anything because no one is currently setting it to anything other
> > than unlimited. Adding this feature would give administrators another
> > tool, a way to control the private data size of a process without
> > restricting its ability to attach to large shared mappings.
>
> That may be a good argument (though "extremely unlikely to break"s
> have a nasty habit of biting). I'd still say that the contribution
> to Committed_AS is more appropriate and more useful here.
You may be right... I suppose everything will bite someone somewhere with a
sufficiently large user base.
As for whether Committed_AS is more appropriate, I'll have to defer to Herbert
on this one. He stated that RLIMIT_DATA no longer does what it was intended
to do, and offered a fix for it, and I agreed with him. I do believe his
patch does a reasonable approximation of the original intent of RLIMIT_DATA,
but I didn't delve into the actual intended use of it once it's fixed.
> > > That change to /proc/PID/status VmData:
> > > - data = mm->total_vm - mm->shared_vm - mm->stack_vm;
> > > + data = mm->total_vm - mm->shared_vm - mm->stack_vm - mm->exec_vm;
> > > looks plausible, but isn't exec_vm already counted as shared_vm,
> > > so now being doubly subtracted? Besides which, we wouldn't want
> > > to change those numbers again without consulting Albert.
> >
> > As I recall, this was added after Herbert discovered that exec_vm is not
> > counted as shared_vm. It's actually mapped as private/readonly.
>
> Mapped private readonly yes, but vm_stat_account() says
> if (file) {
> mm->shared_vm += pages;
> if ((flags & (VM_EXEC|VM_WRITE)) == VM_EXEC)
> mm->exec_vm += pages;
In that code shared_vm includes everything that's mmap()ed, including private
mappings. But if you look at Herbert's patch he has the following change:
if (file) {
- mm->shared_vm += pages;
+ if (flags & VM_SHARED)
+ mm->shared_vm += pages;
if ((flags & (VM_EXEC|VM_WRITE)) == VM_EXEC)
mm->exec_vm += pages;
This means that shared_vm now is truly only memory that's mapped VM_SHARED and
does not include VM_EXEC memory. That necessitates the separate subtraction
of exec_vm in the data calculations.
Dave McCracken
--
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>
next prev parent reply other threads:[~2007-07-10 19:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-10 0:43 [PATCH] include private data mappings in RLIMIT_DATA limit Herbert van den Bergh
2007-07-10 0:43 ` Herbert van den Bergh
2007-07-10 0:54 ` Dave McCracken
2007-07-10 0:54 ` Dave McCracken
2007-07-10 16:58 ` Hugh Dickins
2007-07-10 17:19 ` Dave McCracken
2007-07-10 17:19 ` Dave McCracken
2007-07-10 18:06 ` Hugh Dickins
2007-07-10 18:06 ` Hugh Dickins
2007-07-10 19:12 ` Dave McCracken [this message]
2007-07-10 19:12 ` Dave McCracken
2007-07-10 19:42 ` Hugh Dickins
2007-07-10 19:42 ` Hugh Dickins
2007-07-10 20:09 ` Herbert van den Bergh
2007-07-10 20:09 ` Herbert van den Bergh
2007-07-13 19:18 ` Hugh Dickins
2007-07-13 19:18 ` Hugh Dickins
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=200707101412.19785.dave.mccracken@oracle.com \
--to=dave.mccracken@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=herbert.van.den.bergh@oracle.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.