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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox