From: Paolo Bonzini <pbonzini@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: marcel.a@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com
Subject: Re: [Qemu-devel] [PATCH 0/2] exec: alternative fix for master abort woes
Date: Thu, 07 Nov 2013 18:29:40 +0100 [thread overview]
Message-ID: <527BCE04.9020107@redhat.com> (raw)
In-Reply-To: <20131107164705.GA4572@redhat.com>
Il 07/11/2013 17:47, Michael S. Tsirkin ha scritto:
> That's on kvm with 52 bit address.
> But where I would be concerned is systems with e.g. 36 bit address
> space where we are doubling the cost of the lookup.
> E.g. try i386 and not x86_64.
Tried now...
P_L2_LEVELS pre-patch post-patch
i386 3 6
x86_64 4 6
I timed the inl_from_qemu test of vmexit.flat with both KVM and TCG. With
TCG there's indeed a visible penalty of 20 cycles for i386 and 10 for x86_64
(you can extrapolate to 30 cycles for TARGET_PHYS_ADDR_SPACE_BITS=32 targets).
These can be more or less entirely ascribed to phys_page_find:
TCG | KVM
pre-patch post-patch | pre-patch post-patch
phys_page_find(i386) 13% 25% | 0.6% 1%
inl_from_qemu cycles(i386) 153 173 | ~12000 ~12000
phys_page_find(x86_64) 18% 25% | 0.8% 1%
inl_from_qemu cycles(x86_64) 163 173 | ~12000 ~12000
Thus this patch costs 0.4% in the worst case for KVM, 12% in the worst case
for TCG. The cycle breakdown is:
60 phys_page_find
28 access_with_adjusted_size
24 address_space_translate_internal
20 address_space_rw
13 io_mem_read
11 address_space_translate
9 memory_region_read_accessor
6 memory_region_access_valid
4 helper_inl
4 memory_access_size
3 cpu_inl
(This run reported 177 cycles per access; the total is 182 due to rounding).
It is probably possible to shave at least 10 cycles from the functions below,
or to make the depth of the tree dynamic so that you would save even more
compared to 1.6.0.
Also, compiling with "-fstack-protector" instead of "-fstack-protector-all",
as suggested a while ago by rth, is already giving a savings of 20 cycles.
And of course, if this were a realistic test, KVM's 60x penalty would
be a severe problem---but it isn't, because this is not a realistic setting.
Paolo
next prev parent reply other threads:[~2013-11-07 17:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-07 16:14 [Qemu-devel] [PATCH 0/2] exec: alternative fix for master abort woes Paolo Bonzini
2013-11-07 16:14 ` [Qemu-devel] [PATCH 1/2] split definitions for exec.c and translate-all.c radix trees Paolo Bonzini
2013-11-07 16:14 ` [Qemu-devel] [PATCH 2/2] exec: make address spaces 64-bit wide Paolo Bonzini
2013-11-10 10:31 ` Michael S. Tsirkin
2013-11-11 10:15 ` Paolo Bonzini
2013-11-07 16:21 ` [Qemu-devel] [PATCH 0/2] exec: alternative fix for master abort woes Michael S. Tsirkin
2013-11-07 16:29 ` Paolo Bonzini
2013-11-07 16:47 ` Michael S. Tsirkin
2013-11-07 17:29 ` Paolo Bonzini [this message]
2013-11-07 18:54 ` Michael S. Tsirkin
2013-11-07 19:12 ` Paolo Bonzini
2013-11-11 16:43 ` Michael S. Tsirkin
2013-11-11 16:57 ` Paolo Bonzini
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=527BCE04.9020107@redhat.com \
--to=pbonzini@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=marcel.a@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).