From: Serge Orlov <sorlov@con.mcst.ru>
To: linux-kernel@vger.kernel.org
Cc: Linus Torvalds <torvalds@transmeta.com>, sorlov@mcst.ru
Subject: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.
Date: Tue, 20 Mar 2001 21:28:57 +0300 [thread overview]
Message-ID: <3AB7A169.53F4E4BB@con.mcst.ru> (raw)
Hi,
I upgraded one of our computer happily running 2.2.13 kernel
to 2.4.2. Everything was OK, but compilation time of our C++
project greatly increased (1.4 times slower). I investigated the
issue and found that g++ spends 7 times more time in kernel.
The reason for this is big vm map:
cat /proc/15677/maps |wc -l
2238
15677 -- is cc1plus process, the map looks like this:
.....
4014a000-4014b000 rw-p 00000000 00:00 0
4014b000-4014c000 rw-p 00000000 00:00 0
4014c000-4014d000 rw-p 00000000 00:00 0
4014d000-4014e000 rw-p 00000000 00:00 0
4014e000-4014f000 rw-p 00000000 00:00 0
4014f000-40150000 rw-p 00000000 00:00 0
40150000-40151000 rw-p 00000000 00:00 0
40151000-40152000 rw-p 00000000 00:00 0
......
strace:
.....
15677 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40019000
15677 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40019000
15677 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000
15677 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001b000
15677 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001c000
15677 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001d000
.......
2.4.2:
time g++ -g -Wall -I. -c t_instr.cpp -o t_instr.o
real 0m3.434s
user 0m2.790s
sys 0m0.530s
2.2.13:
time g++ -g -Wall -I. -c t_instr.cpp -o t_instr.o
real 0m3.167s
user 0m2.950s
sys 0m0.070s
I noticed a recent thread (Re: Kernel is unstable) in archives that
ended by Linus:
--- quote ---
Ehh.. If the merging doesn't actually happen, it's always a loss. We've
just spent CPU cycles on doing something useless. And in my tests, that
was the case a lot more than not.
Also, in the expense of taking a page fault, looking one or two levels
deeper in the AVL tree is pretty much not noticeable.
Show me numbers for real applications, and I might care. I saw barely
measurable speedups (and more importantly to me - real simplification)
by
removing it.
Don't bother arguing with "it might.."
Linus
--- end of quote ----
OK, the numbers are here. g++ is 2.96 from RedHat 7.0.
Please, CC me, as I'm not on the list.
Serge.
next reply other threads:[~2001-03-20 18:33 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-20 18:28 Serge Orlov [this message]
2001-03-20 18:43 ` Linux 2.4.2 fails to merge mmap areas, 700% slowdown Linus Torvalds
2001-03-20 18:59 ` Jakob Østergaard
2001-03-21 1:20 ` Kevin Buhr
2001-03-21 1:38 ` 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
[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-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-20 18:43 ` Linux 2.4.2 fails to merge mmap areas, 700% slowdown Jakob Østergaard
-- strict thread matches above, loose matches on Subject: below --
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=3AB7A169.53F4E4BB@con.mcst.ru \
--to=sorlov@con.mcst.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=sorlov@mcst.ru \
--cc=torvalds@transmeta.com \
/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.