From: Ingo Molnar <mingo@elte.hu>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Nick Piggin <npiggin@suse.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
hpa@zytor.com, jeremy@xensource.com, chrisw@sous-sol.org,
zach@vmware.com, rusty@rustcorp.com.au
Subject: Re: lmbench lat_mmap slowdown with CONFIG_PARAVIRT
Date: Fri, 23 Jan 2009 00:04:23 +0100 [thread overview]
Message-ID: <20090122230423.GA19569@elte.hu> (raw)
In-Reply-To: <4978F2A4.8010807@goop.org>
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> Ingo Molnar wrote:
>> Ouch, that looks unacceptably expensive. All the major distros turn
>> CONFIG_PARAVIRT on. paravirt_ops was introduced in x86 with the express
>> promise to have no measurable runtime overhead.
>>
>> ( And i suspect the real life mmap cost is probably even more expensive,
>> as on a Barcelona all of lmbench fits into the cache hence we dont see
>> any real $cache overhead. )
>>
>> Jeremy, any ideas where this slowdown comes from and how it could be
>> fixed?
>>
>
> I just posted a couple of patches to pick some low-hanging fruit. It
> turns out that we don't need to do any pvops calls to do pte flag
> manipulations. I'd be interested to see how much of a difference it
> makes (it reduces the static code size by a few k).
I've tried your patches - but can see no significant reduction in
overhead. I've updated my table with numbers from your patches:
-----------------------------------------------
| Performance counter stats for './mmap-perf' |
-----------------------------------------------
| | |
| defconfig | PARAVIRT=y | +Jeremy
|-----------------------------------------------------------------------
|
| 1311.55452 | 1360.62493 | 1378.94464 task clock (msecs) +3.74%
| | |
| 1 | 1 | 0 CPU migrations
| 91 | 79 | 77 context switches
| 55945 | 55943 | 55980 pagefaults
|.......................................................................
| 3781392474 | 3918777174 | 3907189795 CPU cycles +3.63%
| 1957153827 | 2161280486 | 2161741689 instructions +10.43%
| 50234816 | 51303520 | 50619593 cache references +2.12%
| 5428258 | 5583728 | 5575808 cache misses +2.86%
|
| 437983499 | 478967061 | 479053595 branches +9.36%
| 32486067 | 32336874 | 32377710 branch-misses -0.46%
| |
| 1314.78246 | 1363.69444 | 1357.58161 time elapsed (msecs) +3.72%
| |
------------------------------------------------------------------------
'+Jeremy' is a CONFIG_PARAVIRT=y run done with your patches.
The most stable count is the instruction count:
| 1957153827 | 2161280486 | 2161741689 instructions +10.43%
But your two patches did not reduce the instruction count in any
measurable way.
In any case, it is rather inefficient of me proxy-testing your patches,
you can do these measurements yourself too on any Core2 or later Intel
CPU, by running tip/master plus picking up these two utilities:
http://people.redhat.com/mingo/perfcounters/perfstat.c
http://redhat.com/~mingo/misc/mmap-perf.c
building them and running this (as root):
taskset 1 ./perfstat ./mmap-perf 1
it will give you numbers like the ones above.
Ingo
next prev parent reply other threads:[~2009-01-22 23:04 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-20 11:05 lmbench lat_mmap slowdown with CONFIG_PARAVIRT Nick Piggin
2009-01-20 11:26 ` 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 [this message]
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=20090122230423.GA19569@elte.hu \
--to=mingo@elte.hu \
--cc=chrisw@sous-sol.org \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=jeremy@xensource.com \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
--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.