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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox