From: Jamie Lokier <lk@tantalophile.demon.co.uk>
To: Jakob Østergaard <jakob@unthought.net>,
Kevin Buhr <buhr@stat.wisc.edu>,
linux-kernel@vger.kernel.org
Subject: Re: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.
Date: Sun, 25 Mar 2001 18:47:25 +0200 [thread overview]
Message-ID: <20010325184724.A16840@pcep-jamie.cern.ch> (raw)
In-Reply-To: <Pine.LNX.4.31.0103201042360.1990-100000@penguin.transmeta.com> <vba1yrr7w9v.fsf@mozart.stat.wisc.edu> <15032.1585.623431.370770@pizda.ninka.net> <vbay9ty50zi.fsf@mozart.stat.wisc.edu> <vbaelvp3bos.fsf@mozart.stat.wisc.edu> <20010322193549.D6690@unthought.net> <vbawv9hyuj0.fsf@mozart.stat.wisc.edu> <20010324104849.B9686@unthought.net> <vbabsqrvt6o.fsf@mozart.stat.wisc.edu> <20010325051738.A11943@unthought.net>
In-Reply-To: <20010325051738.A11943@unthought.net>; from jakob@unthought.net on Sun, Mar 25, 2001 at 05:17:38AM +0200
Jakob Østergaard wrote:
> But the bad case was a garbage collector in GCC. The mmap tricks seem like
> some you may be inclined to actually use in something like garbage collectors.
> Are we sure that the developers of all other garbage collectors out there
> foresaw this problem and didn't do mmap tricks ?
On this theme, some garbage collectors like to write-protect individual
pages, to detect which pages are modified between generations. The
kernel has never handled this especially well. It could be argued that
mprotect() and signal() aren't the right way to get this information
though, and it would be better to add a different mechanism.
-- Jamie
next prev parent reply other threads:[~2001-03-25 16:48 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-20 18:28 Serge Orlov
2001-03-20 18:43 ` Linus Torvalds
2001-03-20 18:59 ` Jakob Østergaard
2001-03-21 1:20 ` Kevin Buhr
2001-03-21 6:41 ` Mike Galbraith
2001-03-21 14:56 ` Matthias Urlichs
2001-03-21 15:05 ` Mike Galbraith
2001-03-21 15:59 ` Kurt Garloff
2001-03-21 16:45 ` Mike Galbraith
2001-03-21 20:16 ` Kevin Buhr
2001-03-22 9:04 ` Mike Galbraith
2001-03-22 22:19 ` Kevin Buhr
2001-03-23 7:44 ` Mike Galbraith
2001-03-23 21:36 ` 2.4.2-ac20 patch for process time double-counting (was: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.) Kevin Buhr
2001-03-24 7:49 ` Mike Galbraith
2001-03-24 19:27 ` Kevin Buhr
2001-03-21 1:38 ` Linux 2.4.2 fails to merge mmap areas, 700% slowdown David S. Miller
2001-03-21 20:19 ` Kevin Buhr
2001-03-22 18:23 ` Kevin Buhr
2001-03-22 18:35 ` Jakob Østergaard
2001-03-23 4:32 ` Kevin Buhr
2001-03-24 4:11 ` Zack Weinberg
2001-03-24 21:46 ` Kevin Buhr
2001-03-24 5:02 ` Linus Torvalds
2001-03-24 9:31 ` Jakob Østergaard
2001-03-24 9:48 ` Jakob Østergaard
2001-03-24 19:54 ` Kevin Buhr
2001-03-25 3:17 ` Jakob Østergaard
2001-03-25 16:47 ` Jamie Lokier [this message]
[not found] ` <200103240502.VAA02673@penguin.transmeta.com>
2001-03-24 21:22 ` Kevin Buhr
2001-03-25 3:37 ` Linus Torvalds
2001-03-26 4:22 ` Kevin Buhr
2001-03-23 20:43 ` James Lewis Nance
2001-03-20 18:43 ` Jakob Østergaard
2001-03-21 2:02 Dieter Nützel
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=20010325184724.A16840@pcep-jamie.cern.ch \
--to=lk@tantalophile.demon.co.uk \
--cc=buhr@stat.wisc.edu \
--cc=jakob@unthought.net \
--cc=linux-kernel@vger.kernel.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®