From: Gordan Bobic <gordan@bobich.net>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
Lars Kurth <lars.kurth@xen.org>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: Xen 4.2.2 / KVM / VirtualBox benchmark on Haswell
Date: Thu, 11 Jul 2013 18:49:00 +0100 [thread overview]
Message-ID: <51DEF00C.9080400@bobich.net> (raw)
In-Reply-To: <1373560062.12772.48.camel@Solace>
On 07/11/2013 05:27 PM, Dario Faggioli wrote:
> On gio, 2013-07-11 at 17:23 +0100, George Dunlap wrote:
>> On Thu, Jul 11, 2013 at 11:53 AM, Dario Faggioli
>>> When I tried to use kernel compile as a benchmark for the NUMA effects,
>>> it did not turn out that useful to me (and that's why I switched to
>>> SpecJBB), but perhaps it was me that was doing something wrong...
>>
>> In my experience, kernel-build has excellent memory locality. One
>> effect is that the effect of nested paging on TLB time is almostt nil;
>> I'm not surprised that the caches make the effect of NUMA almost nil
>> as well.
>>
> Not to mention I/O, unless you setup a ramfs backed building
> environment. Again, when I tried, that was my intention, but perhaps I
> failed right at that... Gordan, what about you?
IIRC in my tests the disk I/O was relatively minimal. If you read the
details here:
http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/
you may notice that I actually primed the test by catting everything to
/dev/null, so all the reads should have been coming from the page cache.
I didn't have enough RAM in the machine (only 8GB) to fit all the
produced binaries in tmpfs at the time.
I don't think this had a large impact, though - the iowait time was
about 0% all the time because there were plenty of threads that had
productive compiling work to do while some were waiting to commit to
disk. Since this was on a C2Q, there was no NUMA in play, so if I had to
guess at the major cause of performance degradation, it would be related
to context switching; having said that, I didn't get around to doing any
in-depth profiling to be able to tell for sure. (Speaking of which, how
would one go about profiling things at bare-metal hypervisor level?
I will re-run the test on a new machine at some point and see how it
compares, and this time I will have enough RAM for the whole lot to fit.
Gordan
next prev parent reply other threads:[~2013-07-11 17:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-09 15:27 Xen 4.2.2 / KVM / VirtualBox benchmark on Haswell Lars Kurth
2013-07-09 15:40 ` Thanos Makatos
2013-07-09 15:53 ` Ian Murray
2013-07-09 15:56 ` Thanos Makatos
2013-07-09 16:14 ` Gordan Bobic
2013-07-09 16:21 ` Thanos Makatos
2013-07-09 16:26 ` Gordan Bobic
2013-07-09 15:54 ` Gordan Bobic
2013-07-11 10:53 ` Dario Faggioli
2013-07-11 16:23 ` George Dunlap
2013-07-11 16:27 ` Dario Faggioli
2013-07-11 17:49 ` Gordan Bobic [this message]
2013-07-09 16:52 ` Alex Bligh
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=51DEF00C.9080400@bobich.net \
--to=gordan@bobich.net \
--cc=George.Dunlap@eu.citrix.com \
--cc=dario.faggioli@citrix.com \
--cc=lars.kurth@xen.org \
--cc=xen-devel@lists.xen.org \
/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.