All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.