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 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.