From: ebiederm@xmission.com (Eric W. Biederman)
To: Rik van Riel <riel@conectiva.com.br>
Cc: Richard Gooch <rgooch@ras.ucalgary.ca>,
Daniel Phillips <phillips@bonn-fries.net>,
Adam Kropelin <akropel1@rochester.rr.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.4.18pre3-ac1
Date: 21 Jan 2002 00:01:54 -0700 [thread overview]
Message-ID: <m1zo38faql.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.33L.0201210333460.32617-100000@imladris.surriel.com>
In-Reply-To: <Pine.LNX.4.33L.0201210333460.32617-100000@imladris.surriel.com>
Rik van Riel <riel@conectiva.com.br> writes:
> On Sun, 20 Jan 2002, Richard Gooch wrote:
>
> > Will lazy page table instantiation speed up fork(2) without rmap?
> > If so, then you've got a problem, because rmap will still be slower
> > than non-rmap. Linus will happily grab any speedup and make that the
> > new baseline against which new schemes are compared :-)
But the differences will go down to the noise level. Your average fork
shouldn't need to copy more than one page. So the amount of work is
near constant.
> I guess the difference here is "optimised for lmbench"
> vs. "optimised to be stable in real workloads" ;)
Currently the rmap patch triples the size of the page tables which is
also an issue. Though it is relatively straight forward to reduce
that to simply double the page table size with a order(1) allocation,
so we can remove one pointer.
Unless I am mistaken an every day shell script is fairly fork/exec/exit
intensive operation. And there are probably more shell scripts for
unix than every other kind of program put together.
An additional possible strike against rmap is that walking through
page tables in virtual address order is fairly cache friendly, while a
random walk has more of a cache penalty.
One more case that is difficult for rmap is the highly mapped case of
something like glibc. You can easily get to a thousand entries or
more for a single page. In which case a doubly linked list may be
more appropriate then a singly linked list (for add/insert), but this
again tripples or quadruples the page table size. And none of it
solves having to walk very long lists in some circumstances. The
best you can do is periodically unmapping pages, and then you only
have very long lists for highly active pages.
And to be fair rmap has some advantages over the current system. VM
algorithms are some simpler to code when you can code them however
you want to, instead of being constrained by other parts of the
implementation.
To the true sceptic what remains to be shown is
Eric
next prev parent reply other threads:[~2002-01-21 7:05 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
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 [this message]
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=m1zo38faql.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=akropel1@rochester.rr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=phillips@bonn-fries.net \
--cc=rgooch@ras.ucalgary.ca \
--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