mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hugh Dickins <hugh@veritas.com>
To: Ross Biro <ross.biro@gmail.com>
Cc: Rik van Riel <riel@redhat.com>,
	Ray Fucillo <fucillo@intersystems.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Linus Torvalds <torvalds@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: process creation time increases linearly with shmem
Date: Fri, 26 Aug 2005 19:56:57 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.61.0508261946310.8708@goblin.wat.veritas.com> (raw)
In-Reply-To: <8783be6605082611206dce314e@mail.gmail.com>

On Fri, 26 Aug 2005, Ross Biro wrote:
> On 8/26/05, Rik van Riel <riel@redhat.com> wrote:
> > 
> > Filling in all the page table entries at the first fault to
> > a VMA doesn't make much sense, IMHO.
> > 
> > I suspect we would be better off without that extra complexity,
> > unless there is a demonstrated benefit to it.
> 
> You are probably right, but do you want to put in a patch that might
> have a big performance impact in either direction with out verifying
> it?
> 
> My suggestion is safe, but most likely sub-optimal.  What everyone
> else is suggesting may be far better, but needs to be verified first.

It all has to be verified, and the problem will be that some things
fare well and others badly: how to reach a balanced decision?
Following your suggestion is no more safe than not following it.

> I'm suggesting that we change the code to do the same work fork would
> have done on the first page fault immediately, since it's easy to
> argue that it's not much worse than we have now and much better in
> many cases, and then try to experiment and figure out  what the
> correct solution is.

We don't know what work fork would have done, that information was in
the ptes we decided not to bother to copy.  Perhaps every pte of the
vma was set, perhaps none, perhaps only one.

Also, doing it at fault time has significantly more work to do than
just zipping along the ptes incrementing page counts and clearing bits.
I think; but probably much less extra work than I originally imagined,
since Andrew gave us the gang lookup of the page cache.

All the same, I'm with Rik: one of the great virtues of the original
idea was its simplicity; I'd prefer not to add complexity.

Hugh

  reply	other threads:[~2005-08-26 18:54 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-24 18:43 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 [this message]
     [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
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.61.0508261946310.8708@goblin.wat.veritas.com \
    --to=hugh@veritas.com \
    --cc=fucillo@intersystems.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=riel@redhat.com \
    --cc=ross.biro@gmail.com \
    --cc=torvalds@osdl.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

all inboxes | Powered by JetHome®