From: Andrew Morton <akpm@digeo.com>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: Paolo Ciarrocchi <ciarrocchi@linuxmail.org>,
linux-kernel@vger.kernel.org
Subject: Re: LMbench2.0 results
Date: Sun, 08 Sep 2002 00:51:19 -0700 [thread overview]
Message-ID: <3D7B0177.6A35FE9B@digeo.com> (raw)
In-Reply-To: 20020907200334.GI888@holomorphy.com
William Lee Irwin III wrote:
>
> Paolo Ciarrocchi wrote:
> >> Hi all,
> >> I've just ran lmbench2.0 on my laptop.
> >> Here the results (again, 2.5.33 seems to be "slow", I don't know why...)
>
> On Sat, Sep 07, 2002 at 09:20:56AM -0700, Andrew Morton wrote:
> > The fork/exec/mmap slowdown is the rmap overhead. I have some stuff
> > which partialy improves it.
>
> Hmm, Where does it enter the mmap() path? PTE instantiation is only done
> for the VM_LOCKED case IIRC. Otherwise it should be invisible.
>
lat_mmap seems to do a mmap, faults in ten pages and then
a munmap(). Most of the CPU cost is in cache misses against
the pagetables in munmap().
c012d54c 153 0.569493 do_mmap_pgoff
c012db5c 158 0.588104 find_vma
c01301ec 172 0.640214 filemap_nopage
c0134e84 172 0.640214 release_pages
c0114744 184 0.684881 smp_apic_timer_interrupt
c012ce3c 248 0.9231 handle_mm_fault
c012f738 282 1.04965 find_get_page
c013e2b0 356 1.32509 __set_page_dirty_buffers
c0116294 377 1.40326 do_page_fault
c013e72c 383 1.42559 page_add_rmap
c013e8bc 398 1.48143 page_remove_rmap
c012cb10 425 1.58193 do_no_page
c0109d70 629 2.34125 page_fault
c012b2f4 1036 3.85618 zap_pte_range
c0107048 20205 75.2066 poll_idle
(Multiply everything by four - it's a quad)
Instruction-level profile for -mm5:
c012b2f4 1036 3.85618 0 0 zap_pte_range /usr/src/25/mm/memory.c:325
c012b2f5 2 0.19305 0 0 /usr/src/25/mm/memory.c:325
c012b2fd 1 0.0965251 0 0 /usr/src/25/mm/memory.c:325
c012b300 2 0.19305 0 0 /usr/src/25/mm/memory.c:325
c012b306 1 0.0965251 0 0 /usr/src/25/mm/memory.c:329
c012b309 1 0.0965251 0 0 /usr/src/25/mm/memory.c:329
c012b30f 1 0.0965251 0 0 /usr/src/25/mm/memory.c:331
c012b319 1 0.0965251 0 0 /usr/src/25/mm/memory.c:331
c012b340 1 0.0965251 0 0 /usr/src/25/mm/memory.c:336
c012b348 1 0.0965251 0 0 /usr/src/25/include/asm/highmem.h:80
c012b350 1 0.0965251 0 0 /usr/src/25/include/asm/thread_info.h:75
c012b35a 2 0.19305 0 0 /usr/src/25/include/asm/highmem.h:85
c012b365 2 0.19305 0 0 /usr/src/25/include/asm/highmem.h:86
c012b3c3 2 0.19305 0 0 /usr/src/25/mm/memory.c:337
c012b3d6 1 0.0965251 0 0 /usr/src/25/mm/memory.c:338
c012b3e9 3 0.289575 0 0 /usr/src/25/mm/memory.c:341
c012b3f5 106 10.2317 0 0 /usr/src/25/mm/memory.c:342
c012b3f8 2 0.19305 0 0 /usr/src/25/mm/memory.c:342
c012b3fa 26 2.50965 0 0 /usr/src/25/mm/memory.c:343
c012b3fc 124 11.9691 0 0 /usr/src/25/mm/memory.c:343
c012b405 13 1.25483 0 0 /usr/src/25/mm/memory.c:345
c012b40b 1 0.0965251 0 0 /usr/src/25/mm/memory.c:346
c012b410 2 0.19305 0 0 /usr/src/25/mm/memory.c:348
c012b412 1 0.0965251 0 0 /usr/src/25/mm/memory.c:348
c012b414 62 5.98456 0 0 /usr/src/25/mm/memory.c:349
c012b41b 1 0.0965251 0 0 /usr/src/25/mm/memory.c:350
c012b421 21 2.02703 0 0 /usr/src/25/mm/memory.c:350
c012b427 2 0.19305 0 0 /usr/src/25/mm/memory.c:351
c012b432 2 0.19305 0 0 /usr/src/25/include/asm/bitops.h:244
c012b434 10 0.965251 0 0 /usr/src/25/mm/memory.c:352
c012b437 1 0.0965251 0 0 /usr/src/25/mm/memory.c:352
c012b43d 5 0.482625 0 0 /usr/src/25/mm/memory.c:353
c012b446 7 0.675676 0 0 /usr/src/25/include/linux/mm.h:389
c012b44b 1 0.0965251 0 0 /usr/src/25/include/linux/mm.h:392
c012b44e 1 0.0965251 0 0 /usr/src/25/include/linux/mm.h:392
c012b451 7 0.675676 0 0 /usr/src/25/include/linux/mm.h:393
c012b453 2 0.19305 0 0 /usr/src/25/include/linux/mm.h:393
c012b461 6 0.579151 0 0 /usr/src/25/include/linux/mm.h:396
c012b466 8 0.772201 0 0 /usr/src/25/include/linux/mm.h:396
c012b46f 6 0.579151 0 0 /usr/src/25/mm/memory.c:356
c012b476 15 1.44788 0 0 /usr/src/25/include/asm-generic/tlb.h:105
c012b481 3 0.289575 0 0 /usr/src/25/include/asm-generic/tlb.h:106
c012b490 5 0.482625 0 0 /usr/src/25/include/asm-generic/tlb.h:110
c012b493 7 0.675676 0 0 /usr/src/25/include/asm-generic/tlb.h:110
c012b49a 1 0.0965251 0 0 /usr/src/25/include/asm-generic/tlb.h:110
c012b49d 3 0.289575 0 0 /usr/src/25/include/asm-generic/tlb.h:110
c012b4a0 1 0.0965251 0 0 /usr/src/25/include/asm-generic/tlb.h:110
c012b4a3 8 0.772201 0 0 /usr/src/25/include/asm-generic/tlb.h:111
c012b4aa 13 1.25483 0 0 /usr/src/25/include/asm-generic/tlb.h:111
c012b500 128 12.3552 0 0 /usr/src/25/mm/memory.c:341
c012b504 108 10.4247 0 0 /usr/src/25/mm/memory.c:341
c012b50b 111 10.7143 0 0 /usr/src/25/mm/memory.c:341
c012b50e 99 9.55598 0 0 /usr/src/25/mm/memory.c:341
c012b511 86 8.30116 0 0 /usr/src/25/mm/memory.c:341
c012b51c 4 0.3861 0 0 /usr/src/25/include/asm/thread_info.h:75
c012b521 3 0.289575 0 0 /usr/src/25/mm/memory.c:366
c012b525 1 0.0965251 0 0 /usr/src/25/mm/memory.c:366
c012b526 1 0.0965251 0 0 /usr/src/25/mm/memory.c:366
So it's a bit of rmap in there. I'd have to compare with a 2.4
profile and fiddle a few kernel parameters. But I'm not sure
that munmap of extremely sparsely populated pagtetables is very
interesting?
next prev parent reply other threads:[~2002-09-08 7:32 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-07 12:18 LMbench2.0 results Paolo Ciarrocchi
2002-09-07 12:27 ` Jeff Garzik
2002-09-07 18:53 ` Rik van Riel
2002-09-07 21:44 ` Alan Cox
2002-09-13 22:46 ` Pavel Machek
2002-09-07 14:33 ` James Morris
2002-09-09 22:22 ` Cliff White
2002-09-07 16:20 ` Andrew Morton
2002-09-07 20:03 ` William Lee Irwin III
2002-09-07 23:12 ` Andrew Morton
2002-09-07 23:01 ` William Lee Irwin III
2002-09-07 23:44 ` Martin J. Bligh
2002-09-08 17:07 ` Alan Cox
2002-09-08 18:11 ` Martin J. Bligh
2002-09-08 18:40 ` Andrew Morton
2002-09-08 20:48 ` Hugh Dickins
2002-09-08 21:51 ` Andrew Morton
2002-09-09 21:13 ` Alan Cox
2002-09-09 21:44 ` Andrew Morton
2002-09-09 22:09 ` Alan Cox
2002-09-08 7:51 ` Andrew Morton [this message]
2002-09-08 7:37 ` David S. Miller
2002-09-08 8:28 ` William Lee Irwin III
2002-09-08 8:25 ` David S. Miller
2002-09-08 9:12 ` William Lee Irwin III
2002-09-08 20:02 ` Daniel Phillips
2002-09-09 13:37 ` Rik van Riel
2002-09-09 16:16 ` Daniel Phillips
2002-09-09 16:26 ` Martin J. Bligh
2002-09-09 16:55 ` Daniel Phillips
2002-09-09 17:24 ` Martin J. Bligh
2002-09-09 21:11 ` Alan Cox
2002-09-09 16:52 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2002-09-07 12:40 Paolo Ciarrocchi
2002-09-07 14:09 Shane Shrybman
2002-09-07 18:04 Paolo Ciarrocchi
2002-09-13 22:49 ` Pavel Machek
2002-09-07 18:09 Paolo Ciarrocchi
2002-09-08 7:51 ` Andrew Morton
2002-09-14 18:26 Paolo Ciarrocchi
2002-09-15 18:08 ` Pavel Machek
2002-09-22 12:42 Paolo Ciarrocchi
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=3D7B0177.6A35FE9B@digeo.com \
--to=akpm@digeo.com \
--cc=ciarrocchi@linuxmail.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wli@holomorphy.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