From: Alexander Graf <agraf@suse.de>
To: kvm-ppc@vger.kernel.org
Subject: PVnize instructions
Date: Mon, 21 Jun 2010 15:10:15 +0000 [thread overview]
Message-ID: <4C1F80D7.1050803@suse.de> (raw)
I figured I go and try to find out what the emulation distribution is in
random use cases. The one I measured here was a:
$ for i in `seq 1000`; do ls -la > /dev/null; done
inside the guest. This should give pretty good hints on process spawning
overhead. Below are the results on what is issued most often.
Number of invocations | Opcode in hex | OP | XOP | asm name | sprn
parameter | sprn name
00488520 2101346470 OP: 31 XOP: 83 mfmsr
00487702 1275068452 OP: 19 XOP: 18 rfid
00244822 2108900006 OP: 31 XOP: 339 mfspr 275
SPRN_SPRG3
00244799 2107310758 OP: 31 XOP: 339 mfspr 27
SPR_SRR1
00243110 2103116710 OP: 31 XOP: 467 mtspr 27
SPR_SRR1
00242910 2107245478 OP: 31 XOP: 467 mtspr 26
SPR_SRR0
00242854 2105148070 OP: 31 XOP: 339 mfspr 26
SPR_SRR0
00206254 2101412196 OP: 31 XOP: 178 mtmsrd
00163540 2103509348 OP: 31 XOP: 178 mtmsrd
00162348 2108769190 OP: 31 XOP: 467 mtspr 273
SPRN_SPRG1
00158986 2100380326 OP: 31 XOP: 339 mfspr 273
SPRN_SPRG1
00142246 2080375332 OP: 31 XOP: 274 tlbiel
00122541 2107311014 OP: 31 XOP: 467 mtspr 27
SPR_SRR1
00122527 2105148326 OP: 31 XOP: 467 mtspr 26
SPR_SRR0
00089577 2102592166 OP: 31 XOP: 339 mfspr 19
SPR_DAR
00089562 2102526630 OP: 31 XOP: 339 mfspr 18
SPR_DSISR
00082629 2103443622 OP: 31 XOP: 83 mfmsr
00080937 2098922406 OP: 31 XOP: 467 mtspr 27
SPR_SRR1
00080937 2096759718 OP: 31 XOP: 467 mtspr 26
SPR_SRR0
00054759 2080393764 OP: 31 XOP: 274 tlbiel
00042033 2080440676 OP: 31 XOP: 178 mtmsrd
00042013 2080374950 OP: 31 XOP: 83 mfmsr
00040733 2099315044 OP: 31 XOP: 178 mtmsrd
00039939 2081817254 OP: 31 XOP: 339 mfspr 22
SPR_DECR
00039401 2088829284 OP: 31 XOP: 178 mtmsrd
00039386 2088436646 OP: 31 XOP: 467 mtspr 27
SPR_SRR1
00039377 2088763558 OP: 31 XOP: 83 mfmsr
00039343 2086273958 OP: 31 XOP: 467 mtspr 26
SPR_SRR0
Obviously we could PV mfmsr. Most of the mfmsr and mtmsrs can also be
easily replaced by stda/lda to a negative address with a magic page.
Rfid is pretty much impossible, mtmsrd is _very_ difficult without more
logic inside the guest. The only way around tlbiel would be a queuing
invalidation mechanism - and I doubt that's possible as the kernel
expects the page to be gone instantly.
Overall, this looks pretty promising though. Apparently > 60% of the
emulated instructions can be pretty easily patched to non-emulated ones.
So this is definitely the next low hanging performance fruit to get!
Alex
next reply other threads:[~2010-06-21 15:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-21 15:10 Alexander Graf [this message]
2010-06-22 20:30 ` PVnize instructions Alexander Graf
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=4C1F80D7.1050803@suse.de \
--to=agraf@suse.de \
--cc=kvm-ppc@vger.kernel.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.