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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.