From: Linus Torvalds <torvalds@osdl.org>
To: Rik van Riel <riel@redhat.com>
Cc: Hugh Dickins <hugh@veritas.com>,
Andrea Arcangeli <andrea@suse.de>,
William Lee Irwin III <wli@holomorphy.com>,
Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@osdl.org>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: anon_vma RFC2
Date: Sat, 13 Mar 2004 10:57:01 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.58.0403131048340.900@ppc970.osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0403131227210.15971-100000@chimarrao.boston.redhat.com>
On Sat, 13 Mar 2004, Rik van Riel wrote:
>
> No, Linus is right.
>
> If a child process uses mremap(), it stands to reason that
> it's about to use those pages for something.
That's not necessarily true, since it's entirely possible that it's just a
realloc(), and the old part of the allocation would have been left alone.
That said, I suspect that
- mremap() isn't all _that_ common in the first place
- it's even more rare to do a fork() and then a mremap() (ie most of the
time I suspect the page count will be 1, and no COW is necessary). Most
apps tend to exec() after a fork.
- I agree that in at least part of the remaining cases we _would_ COW the
pages anyway.
I suspect that the only common "no execve after fork" usage is for a few
servers, especially the traditional UNIX kind (ie using processes are
fairly heavy-weight threads). It could be interesting to see numbers.
But basically I'm inclined to believe that the "unnecessary COW" case is
_so_ rare, that if it allows us to make other things simpler (and thus
more stable and likely faster) it is worth it. Especially the simplicity
just appeals to me.
I just think that if mremap() causes so many problems for reverse mapping,
we should make _that_ the expensive operation, instead of making
everything else more complicated. After all, if it turns out that the
"early COW" behaviour I suggest can be a performance problem for some
(rare) circumstances, then the fix for that is likely to just let
applications know that mremap() can be expensive.
(It's still likely to be a lot cheaper than actually doing a new
mmap+memcpy+munmap, so it's not like mremap would become pointless).
Linus
next prev parent reply other threads:[~2004-03-13 18:50 UTC|newest]
Thread overview: 125+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-08 20:24 objrmap-core-1 (rmap removal for file mappings to avoid 4:4 in <=16G machines) Andrea Arcangeli
2004-03-08 20:39 ` Linus Torvalds
2004-03-08 21:23 ` Andrew Morton
2004-03-08 23:02 ` Andrea Arcangeli
2004-03-08 23:21 ` Andrew Morton
2004-03-08 23:40 ` Andrea Arcangeli
2004-03-09 0:10 ` Andrew Morton
2004-03-09 0:35 ` Andrea Arcangeli
2004-03-09 0:59 ` Andrew Morton
2004-03-09 8:31 ` Ingo Molnar
2004-03-09 8:44 ` William Lee Irwin III
2004-03-09 9:03 ` Ingo Molnar
2004-03-09 14:51 ` Andrea Arcangeli
2004-03-09 15:09 ` Ingo Molnar
2004-03-09 15:24 ` Andrea Arcangeli
2004-03-09 16:10 ` Ingo Molnar
2004-03-09 16:35 ` Andrea Arcangeli
2004-03-08 21:02 ` Andrew Morton
2004-03-08 22:34 ` Andrea Arcangeli
2004-03-09 2:46 ` Andrew Morton
2004-03-08 21:28 ` Arjan van de Ven
2004-03-08 23:08 ` Andrea Arcangeli
2004-03-09 7:47 ` Ingo Molnar
2004-03-09 15:21 ` Andrea Arcangeli
2004-03-09 15:36 ` Ingo Molnar
2004-03-09 16:33 ` Andrea Arcangeli
2004-03-09 17:23 ` Martin J. Bligh
2004-03-09 19:57 ` Ingo Molnar
2004-03-09 20:27 ` Andrea Arcangeli
2004-03-10 11:35 ` Ingo Molnar
2004-03-10 12:32 ` Andrea Arcangeli
2004-03-09 10:52 ` [lockup] " Ingo Molnar
2004-03-09 11:02 ` Ingo Molnar
2004-03-09 11:09 ` Andrew Morton
2004-03-09 11:49 ` Ingo Molnar
2004-03-09 12:32 ` William Lee Irwin III
2004-03-09 16:03 ` Andrea Arcangeli
2004-03-10 10:36 ` RFC anon_vma previous (i.e. full objrmap) Andrea Arcangeli
2004-03-10 10:40 ` RFC anon_vma preview " Andrea Arcangeli
2004-03-10 10:54 ` RFC anon_vma previous " Ingo Molnar
2004-03-11 6:52 ` anon_vma RFC2 Andrea Arcangeli
2004-03-11 13:23 ` Hugh Dickins
2004-03-11 13:56 ` Andrea Arcangeli
2004-03-11 21:54 ` Hugh Dickins
2004-03-12 1:47 ` Andrea Arcangeli
2004-03-12 2:20 ` Andrea Arcangeli
2004-03-12 3:28 ` Rik van Riel
2004-03-12 12:21 ` Andrea Arcangeli
2004-03-12 12:40 ` Rik van Riel
2004-03-12 13:11 ` Andrea Arcangeli
2004-03-12 16:25 ` Rik van Riel
2004-03-12 17:13 ` Andrea Arcangeli
2004-03-12 17:23 ` Rik van Riel
2004-03-12 17:44 ` Andrea Arcangeli
2004-03-12 18:18 ` Rik van Riel
2004-03-12 18:25 ` Linus Torvalds
2004-03-12 18:48 ` Rik van Riel
2004-03-12 19:02 ` Chris Friesen
2004-03-12 19:06 ` Rik van Riel
2004-03-12 19:10 ` Chris Friesen
2004-03-12 19:14 ` Rik van Riel
2004-03-12 20:27 ` Andrea Arcangeli
2004-03-12 20:32 ` Rik van Riel
2004-03-12 20:49 ` Andrea Arcangeli
2004-03-12 21:08 ` Jamie Lokier
2004-03-12 12:42 ` Andrea Arcangeli
2004-03-12 12:46 ` William Lee Irwin III
2004-03-12 13:24 ` Andrea Arcangeli
2004-03-12 13:40 ` William Lee Irwin III
2004-03-12 13:55 ` Hugh Dickins
2004-03-12 16:01 ` Andrea Arcangeli
2004-03-12 16:17 ` Linus Torvalds
2004-03-13 0:28 ` William Lee Irwin III
2004-03-13 14:43 ` Rik van Riel
2004-03-13 16:18 ` Linus Torvalds
2004-03-13 17:24 ` Hugh Dickins
2004-03-13 17:28 ` Rik van Riel
2004-03-13 17:41 ` Hugh Dickins
2004-03-13 18:08 ` Andrea Arcangeli
2004-03-13 17:54 ` Andrea Arcangeli
2004-03-13 17:55 ` Andrea Arcangeli
2004-03-13 18:57 ` Linus Torvalds [this message]
2004-03-13 19:14 ` Hugh Dickins
2004-03-13 17:48 ` Andrea Arcangeli
2004-03-13 17:33 ` Andrea Arcangeli
2004-03-13 17:53 ` Hugh Dickins
2004-03-13 18:13 ` Andrea Arcangeli
2004-03-13 19:35 ` Hugh Dickins
2004-03-13 17:57 ` Rik van Riel
2004-03-12 13:43 ` Hugh Dickins
2004-03-12 15:56 ` Andrea Arcangeli
2004-03-12 16:12 ` Hugh Dickins
2004-03-12 16:39 ` Andrea Arcangeli
2004-03-11 17:33 ` Andrea Arcangeli
2004-03-11 22:20 ` Rik van Riel
2004-03-11 23:43 ` Hugh Dickins
2004-03-12 3:20 ` Rik van Riel
2004-03-09 17:22 ` [lockup] Re: objrmap-core-1 (rmap removal for file mappings to avoid 4:4 in <=16G machines) Rik van Riel
2004-03-09 17:56 ` Andrea Arcangeli
2004-03-09 15:59 ` Andrea Arcangeli
2004-03-09 16:07 ` Ingo Molnar
2004-03-09 16:08 ` Ingo Molnar
2004-03-09 16:39 ` Andrea Arcangeli
2004-03-09 19:33 ` Ingo Molnar
2004-03-09 16:39 ` Andrea Arcangeli
2004-03-09 15:41 ` Andrea Arcangeli
2004-03-15 19:47 ` Marcelo Tosatti
2004-03-15 22:00 ` Andrea Arcangeli
2004-03-16 7:39 ` Marcelo Tosatti
2004-03-16 13:50 ` Andrea Arcangeli
2004-03-11 20:09 anon_vma RFC2 Manfred Spraul
[not found] <20040310080000.GA30940@dualathlon.random>
2004-03-10 13:01 ` [lockup] Re: objrmap-core-1 (rmap removal for file mappings to avoid 4:4 in <=16G machines) Rik van Riel
2004-03-10 13:50 ` Andrea Arcangeli
2004-03-12 17:05 ` anon_vma RFC2 Rajesh Venkatasubramanian
2004-03-12 17:26 ` Andrea Arcangeli
2004-03-12 21:16 ` Rajesh Venkatasubramanian
2004-03-13 17:55 ` Rajesh Venkatasubramanian
2004-03-13 18:16 ` Andrea Arcangeli
2004-03-13 19:40 ` Rajesh Venkatasubramanian
2004-03-14 0:23 ` Andrea Arcangeli
2004-03-14 0:52 ` Linus Torvalds
2004-03-14 1:01 ` William Lee Irwin III
2004-03-14 1:07 ` Rik van Riel
2004-03-14 1:19 ` William Lee Irwin III
2004-03-14 1:41 ` Rik van Riel
2004-03-14 2:27 ` William Lee Irwin III
2004-03-14 1:15 ` Linus Torvalds
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=Pine.LNX.4.58.0403131048340.900@ppc970.osdl.org \
--to=torvalds@osdl.org \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=riel@redhat.com \
--cc=wli@holomorphy.com \
/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;
as well as URLs for NNTP newsgroup(s).