qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Xin Tong <trent.tong@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] save compiled qemu traces.
Date: Mon, 09 Dec 2013 15:25:47 +0000	[thread overview]
Message-ID: <8761qy6o78.fsf@linaro.org> (raw)
In-Reply-To: <CA+JLOisZUXdjaZBk6CLix2Sb6aBF2CafTAXmS9j-XiHxw3+hww@mail.gmail.com>


trent.tong@gmail.com writes:

> Does anyone have profiles on how much time QEMU spends in translating
> instructions. QEMU does not have a baseline interpreter nor does it
> translate on trace-granularity.  so i imagine QEMU must spend quite a bit
> of time translating instructions.

Not as much as you'd think. The translation stage isn't very complex and
blocks only get translated once (modulo exceptions and self modifying
code). If you run perf on your task you should see most of the time is
spent in the generated code - if not please send the test case to the
list.

I suspect the more useful statistic would be getting a break down of the
translation blocks and seeing which ones are the most heavily used and
examining if QEMU has done as good a job as it can of translating them.  

> Is it possible for QEMU to obviate some of the translations by attaching a
> signature (e.g. a hash) with every translated basic block and try to reuse
> translated basic block based on the signature as much as possible ? Reuses
> can be a result of rerunning programs or same libraries statically linked
> to programs.

Your right a translation cache *could* save some translation time,
especially if you end up translating the same program over and over
again. Having said that you might find the cost of computing the
checksum obviates any speed-up from skipping the translation. After all
QEMU only needs to look at each subject instruction once normally.

Using QEMU  linux-user for cross building would be the obvious pain
point. However as the usual use case is building for embedded platforms
most users are just happy to fully utilise their 80-core build machines
in preference to having a farm of slow embedded processors.

> This could end up saving some translation time.

I think you would need to do some performance analysis and come up with
some numbers before you made that assumption.

Cheers,

-- 
Alex Bennée
QEMU/KVM Hacker for Linaro

  reply	other threads:[~2013-12-09 15:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-09  6:36 [Qemu-devel] save compiled qemu traces Xin Tong
2013-12-09 15:25 ` Alex Bennée [this message]
2013-12-12  4:07   ` Xin Tong
2013-12-12  4:51     ` Xin Tong
2013-12-12 13:37     ` Laurent Desnogues
2013-12-09 15:32 ` Peter Maydell
2013-12-10  2:41   ` Xin Tong
2013-12-10 10:04   ` Alex Bennée

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=8761qy6o78.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=trent.tong@gmail.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;
as well as URLs for NNTP newsgroup(s).