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: 13 Jan 2002 22:47:56 -0700 [thread overview]
Message-ID: <m13d19qy9f.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.33L.0201140052030.32617-100000@imladris.surriel.com>
In-Reply-To: <Pine.LNX.4.33L.0201140052030.32617-100000@imladris.surriel.com>
Rik van Riel <riel@conectiva.com.br> writes:
> On Sun, 13 Jan 2002, Adam Kropelin wrote:
>
> > From: "Alan Cox" <alan@redhat.com>
> >
> > > People keep bugging me about the -ac tree stuff so this is whats in my
> > > current internal diff with the ll patch and the ide changes excluded.
>
> > For the sake of completeness I ran my large inbound FTP transfer test
> > (details in the "Writeout in recent kernels..." thread) on this
> > release. Performance and observed writeout behavior was essentially
> > the same as for 2.4.17, both stock and with -rmap11a. Transfer time
> > was 6:56 and writeout was uneven. 2.4.13-ac7 is still the winner by a
> > significant margin.
>
> I'm looking into this bug, I just finished the first large
> dbench test set on 2.4.17-rmap11b with 512 MB RAM, tomorrow
> I'll run them with 128 and 32 MB of RAM.
>
> Luckily you have already shown the other recent kernels to
> have the same performance, so I only have to do half a day
> of testing. I'll try to track down this bug and get it fixed.
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. 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.
Just my 2 cents so we don't forget the caveats of the reverse map
approach.
Eric
next prev parent reply other threads:[~2002-01-14 5:51 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 [this message]
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
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=m13d19qy9f.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