From: Nick Piggin <npiggin@suse.de>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
hpa@zytor.com, jeremy@xensource.com, chrisw@sous-sol.org,
zach@vmware.com, rusty@rustcorp.com.au
Subject: lmbench lat_mmap slowdown with CONFIG_PARAVIRT
Date: Tue, 20 Jan 2009 12:05:42 +0100 [thread overview]
Message-ID: <20090120110542.GE19505@wotan.suse.de> (raw)
Hi,
I'm looking at regressions since 2.6.16, and one is lat_mmap has slowed
down. On further investigation, a large part of this is not due to a
_regression_ as such, but the introduction of CONFIG_PARAVIRT=y.
Now, it is true that lat_mmap is basically a microbenchmark, however it
is exercising the memory mapping and page fault handler paths, so we're
talking about pretty important paths here. So I think it should be of
interest.
I've run the tests on a 2s8c AMD Barcelona system, binding the test to
CPU0, and running 100 times (stddev is a bit hard to bring down, and
my scripts needed 100 runs in order to pick up much smaller changes in
the results -- for CONFIG_PARAVIRT, just a couple of runs should show
up the problem).
Times I believe are in nanoseconds for lmbench, anyway lower is better.
non pv AVG=464.22 STD=5.56
paravirt AVG=502.87 STD=7.36
Nearly 10% performance drop here, which is quite a bit... hopefully people
are testing the speed of their PV implementations against non-PV bare
metal :)
CPU: AMD64 family10, speed 2000 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 10000
samples % symbol name
BASE
49749 32.6336 read_tsc
10151 6.6587 __up_read
7363 4.8299 unmap_vmas
7072 4.6390 mnt_drop_write
4107 2.6941 do_page_fault
4090 2.6829 rb_get_reader_page
3601 2.3621 apic_timer_interrupt
3537 2.3202 set_page_dirty
3435 2.2532 mnt_want_write
3302 2.1660 default_idle
2990 1.9613 idle_cpu
2904 1.9049 file_update_time
2789 1.8295 set_page_dirty_balance
2712 1.7790 retint_swapgs
2455 1.6104 __do_fault
2231 1.4635 release_pages
1989 1.3047 rb_buffer_peek
1895 1.2431 ring_buffer_consume
1572 1.0312 handle_mm_fault
1554 1.0194 put_page
1461 0.9584 sync_buffer
1196 0.7845 clear_page_c
1145 0.7511 rb_advance_reader
1144 0.7504 hweight64
1084 0.7111 getnstimeofday
1076 0.7058 __set_page_dirty_no_writeback
1020 0.6691 mark_page_accessed
751 0.4926 tick_do_update_jiffies64
CONFIG_PARAVIRT
8924 7.8849 native_safe_halt
8823 7.7957 native_read_tsc
6201 5.4790 default_spin_lock_flags
5806 5.1300 unmap_vmas
3996 3.5307 handle_mm_fault
3954 3.4936 rb_get_reader_page
3752 3.3151 __do_fault
2908 2.5694 getnstimeofday
2303 2.0348 apic_timer_interrupt
2183 1.9288 find_busiest_group
2057 1.8175 do_page_fault
2057 1.8175 hweight64
2017 1.7821 set_page_dirty
1926 1.7017 get_next_timer_interrupt
1781 1.5736 release_pages
1702 1.5038 native_pte_val
1620 1.4314 native_sched_clock
1588 1.4031 rebalance_domains
1558 1.3766 run_timer_softirq
1531 1.3527 __down_read_trylock
1505 1.3298 native_pmd_val
1445 1.2767 find_get_page
1369 1.2096 find_next_bit
1356 1.1981 __ticket_spin_lock
1225 1.0824 shmem_getpage
1169 1.0329 radix_tree_lookup_slot
1166 1.0302 vm_normal_page
987 0.8721 scheduler_tick
next reply other threads:[~2009-01-20 11:05 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-20 11:05 Nick Piggin [this message]
2009-01-20 11:26 ` lmbench lat_mmap slowdown with CONFIG_PARAVIRT Ingo Molnar
2009-01-20 12:34 ` Nick Piggin
2009-01-20 12:45 ` Ingo Molnar
2009-01-20 13:41 ` Nick Piggin
2009-01-20 14:03 ` Ingo Molnar
2009-01-20 14:14 ` Nick Piggin
2009-01-20 14:17 ` Ingo Molnar
2009-01-20 14:41 ` Nick Piggin
2009-01-20 15:00 ` Ingo Molnar
2009-01-20 15:13 ` Ingo Molnar
2009-01-20 19:37 ` Ingo Molnar
2009-01-20 20:45 ` Jeremy Fitzhardinge
2009-01-20 20:56 ` Ingo Molnar
2009-01-21 7:27 ` Nick Piggin
2009-01-21 22:23 ` Jeremy Fitzhardinge
2009-01-22 22:28 ` Zachary Amsden
2009-01-22 22:44 ` Jeremy Fitzhardinge
2009-01-22 22:49 ` H. Peter Anvin
2009-01-22 22:58 ` Zachary Amsden
2009-01-22 23:52 ` H. Peter Anvin
2009-01-23 0:08 ` Jeremy Fitzhardinge
2009-01-22 22:55 ` Zachary Amsden
2009-01-23 0:14 ` Jeremy Fitzhardinge
2009-01-27 7:59 ` Ingo Molnar
2009-01-27 8:24 ` Jeremy Fitzhardinge
2009-01-27 10:17 ` Jeremy Fitzhardinge
2009-01-20 19:05 ` Zachary Amsden
2009-01-20 19:31 ` Ingo Molnar
2009-01-22 22:26 ` Jeremy Fitzhardinge
2009-01-22 23:04 ` Ingo Molnar
2009-01-22 23:30 ` Zachary Amsden
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=20090120110542.GE19505@wotan.suse.de \
--to=npiggin@suse.de \
--cc=chrisw@sous-sol.org \
--cc=hpa@zytor.com \
--cc=jeremy@xensource.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@linux-foundation.org \
--cc=zach@vmware.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.