public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Rik van Riel <riel@conectiva.com.br>
Cc: Adam Kropelin <akropel1@rochester.rr.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.4.18pre3-ac1
Date: 14 Jan 2002 00:25:16 -0700	[thread overview]
Message-ID: <m1y9j1pf6r.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.33L.0201140409260.32617-100000@imladris.surriel.com>
In-Reply-To: <Pine.LNX.4.33L.0201140409260.32617-100000@imladris.surriel.com>

Rik van Riel <riel@conectiva.com.br> writes:

> On 13 Jan 2002, Eric W. Biederman wrote:
> > Rik van Riel <riel@conectiva.com.br> writes:
> 
> > Rik while you are looking at your reverse mapping code, I would like
> > to call to your attention the at least trippling of times for fork.
> 
> Dave McCracken has measured this on his system, it seems to vary
> from between 10% for bash to 400% for a process with 10 MB of memory.

O.k. That sounds about like what I was expecting.
 
> This is a problem which will need to be solved, a number of designs
> on how to deal with this are ready, implementation needs to be done.

 
> > I wouldn't be surprised if the reason your rmap vm handles things like
> > gcc -j better than the stock kernel is simply the reduced number of
> > processes, due to slower forking.
> 
> I really doubt this, since gcc spends so much more time doing
> real work than forking that the time used in fork can be ignored,
> even if it gets 3 times slower.

But for make -j the forking is done by make and it is nearly a
fork bomb, there is simply a linear increase in the number of processes
instead of an exponential one.  So I will at least hold this as a candidate
for the make -j kernel fixes.

> > Just my 2 cents so we don't forget the caveats of the reverse map
> > approach.
> 
> The main way we can speed up fork easily is by not copying the
> page tables at all at fork time but filling them in later at page
> fault time. While this might look like it's just moving the overhead
> from one place to another, but for the typical fork()+exec() case it
> means (1) we don't copy the page tables at fork time (2) we don't
> need to free them at exec time (3) after the exec, the parent can
> just take back the complete page tables without having to take COW
> faults on all its pages.

Which is definitely a win.  Perhaps we could even have paged page tables
at that point.

There is a second piece that should make things faster as well.  Adopt
the a BSD style page table allocation where we do an order 1 allocation
and allocate both the page table and the reverse page tables all in the same
chunk of memory.  Which means you can jump from one to the other with pointer
arithmetic.  So you can lose one element of your reverse page table chain
structure.

Eric

  reply	other threads:[~2002-01-14  7:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-13 21:44 Linux 2.4.18pre3-ac1 Alan Cox
2002-01-13 19:23 ` Thiago Rondon
2002-01-13 22:52 ` Ville Herva
2002-01-13 22:57   ` Alan Cox
2002-01-14  0:15 ` Adam Kropelin
2002-01-14  0:47   ` Alan Cox
2002-01-14  2:13     ` Benjamin LaHaise
2002-01-14  2:54   ` Rik van Riel
2002-01-14  5:47     ` Eric W. Biederman
2002-01-14  6:17       ` Rik van Riel
2002-01-14  7:25         ` Eric W. Biederman [this message]
2002-01-14  9:28           ` David S. Miller
2002-01-14 12:05             ` Rik van Riel
2002-01-21  3:46           ` Daniel Phillips
2002-01-21  5:30             ` Richard Gooch
2002-01-21  5:34               ` Rik van Riel
2002-01-21  7:01                 ` Eric W. Biederman
2002-01-21 12:02                   ` Rik van Riel
2002-01-21 14:02                   ` Daniel Phillips
2002-01-21 13:22               ` Daniel Phillips

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=m1y9j1pf6r.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=akropel1@rochester.rr.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@conectiva.com.br \
    /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