From: Hugh Dickins <hughd@google.com>
To: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Roland Dreier <roland@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH RFC] mm: account VMA before forced-COW via /proc/pid/mem
Date: Fri, 6 Apr 2012 21:21:38 -0700 (PDT) [thread overview]
Message-ID: <alpine.LSU.2.00.1204062104090.4297@eggly.anvils> (raw)
In-Reply-To: <4F7D5859.5050106@openvz.org>
On Thu, 5 Apr 2012, Konstantin Khlebnikov wrote:
> Oleg Nesterov wrote:
> > On 04/04, Konstantin Khlebnikov wrote:
> > > Oleg Nesterov wrote:
> > > > On 04/02, Konstantin Khlebnikov wrote:
> > > > >
> > > > > Currently kernel does not account read-only private mappings into
> > > > > memory commitment.
> > > > > But these mappings can be force-COW-ed in get_user_pages().
> > > >
> > > > Heh. tail -n3 Documentation/vm/overcommit-accounting
> > > > may be you should update it then.
> > >
> > > I just wonder how fragile this accounting...
> >
> > I meant, this patch could also remove this "TODO" from the docs.
>
> Actually I dug into this code for killing VM_ACCOUNT vma flag.
> Currently we cannot do this only because asymmetry in mprotect_fixup():
> it account vma on read-only -> writable conversion, but keep on backward
> operation.
> Probably we can kill this asymmetry, and after that we can recognize
> accountable vma
> by its others flags state, so we don't need special VM_ACCOUNT for this.
(I believe the VM_ACCOUNT flag will need to stay.)
But this is just a quick note to say that I'm not ignoring you: I have
a strong interest in this, but only now found time to look through the
thread and ponder, and I'm not yet ready to decide.
I've long detested that behaviour of GUP write,force, and my strong
preference would be not to layer more strangeness upon strangeness,
but limit the damage by making GUP write,force fail in that case,
instead of inserting a PageAnon page into a VM_SHARED mapping.
I think it's unlikely that it will cause a regression in real life
(it already fails if you did not open the mmap'ed file for writing),
but it would be a user-visible change in behaviour, and I've research
to do before arriving at a conclusion.
Hugh
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-04-07 4:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-02 15:36 Konstantin Khlebnikov
2012-04-03 14:37 ` Oleg Nesterov
2012-04-04 9:59 ` Konstantin Khlebnikov
2012-04-04 15:41 ` Oleg Nesterov
2012-04-05 8:31 ` Konstantin Khlebnikov
2012-04-07 4:21 ` Hugh Dickins [this message]
2012-04-07 5:11 ` Konstantin Khlebnikov
2012-04-10 0:34 ` Hugh Dickins
2012-04-07 17:33 ` Oleg Nesterov
2012-04-10 1:04 ` Hugh Dickins
2012-04-10 1:35 ` Oleg Nesterov
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=alpine.LSU.2.00.1204062104090.4297@eggly.anvils \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=khlebnikov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=oleg@redhat.com \
--cc=roland@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox