Re: [Qemu-devel] qemu-user performance

["Emilio G. Cota" <cota@braap.org>]

On Fri, Nov 16, 2018 at 14:55:01 +0100, Etienne Dublé wrote:
(snip)
> So the idea is: what if we could share the cache of code already translated
> between all those processes?
> There would be sereral ways to achieve this:
> * use a shared memory area for the cache, and locking mechanisms.
> * have a (maybe optional) daemon that would manage the cache of all
> processes.
> * python-like model: the first time a binary or library is translated, save
> this translated code in a cache file next to the original file, with
> different extension.
> Please let me know what you think about it, if something similar has already
> been studied, or if I miss something obvious.

There's a recent paper that implements something similar to what you
propose:

  "A General Persistent Code Caching Framework for Dynamic Binary
  Translation (DBT)", ATC'16
  https://www.usenix.org/system/files/conference/atc16/atc16_paper-wang.pdf

Note that in that paper they compare against HQEMU, and not against
upstream QEMU. I presume they chose HQEMU because it spends
more effort than QEMU in trying to generate better code for hot
code paths (they use LLVM in a separate thread for those), which
means that code generation can be a bottleneck for some workloads
(e.g. SPEC's gcc or perlbench).

QEMU, on the other hand, generates much simpler code, and as a result
it is rare to find workloads where code generation is a bottleneck.
(You can measure this with perf top in your system; make sure you
configured QEMU with --disable-strip to keep the symbols after
"make install".)
So until QEMU gets some sort of "hot code optimization" that makes
translation more expensive, there's little point in implementing
persistent code caching for it.

As an aside, what QEMU version are you running? Performance has
improved quite a bit (particularly for integer workloads) in the
last couple of years, e.g. see the perf improvements from v2.6 to
v2.11 here:
  https://imgur.com/a/5P5zj

Cheers,

		Emilio