From: Linus Torvalds <torvalds@osdl.org>
To: Hugh Dickins <hugh@veritas.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
Rik van Riel <riel@redhat.com>,
Ray Fucillo <fucillo@intersystems.com>,
linux-kernel@vger.kernel.org
Subject: Re: process creation time increases linearly with shmem
Date: Fri, 26 Aug 2005 11:07:30 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.58.0508261052330.3317@g5.osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.61.0508261220230.4697@goblin.wat.veritas.com>
On Fri, 26 Aug 2005, Hugh Dickins wrote:
>
> I see some flaws in the various patches posted, including Rik's.
> Here's another version - doing it inside copy_page_range, so this
> kind of vma special-casing is over in mm/ rather than kernel/.
I like this approach better, but I don't understand your particular
choice of bits.
> + * Assume the fork will probably exec: don't waste time copying
> + * ptes where a page fault will fill them correctly afterwards.
> + */
> + if ((vma->vm_flags & (VM_MAYSHARE|VM_HUGETLB|VM_NONLINEAR|VM_RESERVED))
> + == VM_MAYSHARE)
> + return 0;
> +
> if (is_vm_hugetlb_page(vma))
> return copy_hugetlb_page_range(dst_mm, src_mm, vma);
First off, if you just did it below the hugetlb check, you'd not need to
check hugetlb again. And while I understand VM_NONLINEAR and VM_RESERVED,
can you please comment on why VM_MAYSHARE is so important, and why no
other information matters.
Now, VM_MAYSHARE is a sign of the mapping being a shared mapping. Fair
enough. But afaik, a shared anonymous mapping absolutely needs its page
tables copied, because those page tables contains either the pointers to
the shared pages, or the swap entries.
So I really think you need to verify that it's a file mapping too.
Also, arguably, there are other cases that may or may not be worth
worrying about. What about non-shared non-writable file mappings? What
about private mappings that haven't been COW'ed?
So I think that in addition to your tests, you should test for
"vma->vm_file", and you could toy with testing for "vma->anon_vma" being
NULL (the latter will cause a _lot_ of hits, because any read-only private
mapping will trigger, but it's a good stress-test and conceptually
interesting, even if I suspect it will kill any performance gain through
extra minor faults in the child).
Linus
next prev parent reply other threads:[~2005-08-26 18:07 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-24 18:43 process creation time increases linearly with shmem Ray Fucillo
2005-08-25 0:14 ` Nick Piggin
2005-08-25 13:07 ` Ray Fucillo
2005-08-25 13:13 ` Andi Kleen
2005-08-25 14:28 ` Nick Piggin
2005-08-25 17:31 ` Rik van Riel
2005-08-26 1:26 ` Nick Piggin
2005-08-26 1:50 ` Rik van Riel
2005-08-26 3:56 ` Linus Torvalds
2005-08-26 11:49 ` Hugh Dickins
2005-08-26 14:26 ` Nick Piggin
2005-08-26 17:00 ` Ray Fucillo
2005-08-26 17:53 ` Rik van Riel
2005-08-26 18:20 ` Ross Biro
2005-08-26 18:56 ` Hugh Dickins
[not found] ` <8783be660508260915524e2b1e@mail.gmail.com>
2005-08-26 16:38 ` Hugh Dickins
2005-08-26 16:43 ` Ross Biro
2005-08-26 18:07 ` Linus Torvalds [this message]
2005-08-26 18:41 ` Hugh Dickins
2005-08-26 22:55 ` Linus Torvalds
2005-08-26 23:10 ` Rik van Riel
2005-08-26 23:23 ` Linus Torvalds
2005-08-27 15:05 ` Nick Piggin
2005-08-28 4:26 ` Hugh Dickins
2005-08-28 6:49 ` Nick Piggin
2005-08-29 23:33 ` Ray Fucillo
2005-08-30 0:29 ` Nick Piggin
2005-08-30 1:03 ` Linus Torvalds
2005-08-30 0:34 ` Linus Torvalds
2005-08-25 14:05 Parag Warudkar
2005-08-25 14:22 ` Andi Kleen
2005-08-25 14:35 ` Nick Piggin
2005-08-25 14:47 ` Parag Warudkar
2005-08-25 15:56 ` Andi Kleen
2005-12-14 14:07 Brice Oliver
2005-12-14 16:21 ` 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=Pine.LNX.4.58.0508261052330.3317@g5.osdl.org \
--to=torvalds@osdl.org \
--cc=fucillo@intersystems.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=riel@redhat.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).