It's just the overhead of running a cross architecture emulation. For Arm to x86_64, the overhead is very high. I was wondering if there is some command line argument that I was missing in order to reduce this. I read somewhere that the tcg cache is defaulted to some value, and wanted to check in to make sure that that wasn't it.
I can't see it right now, I was just looking into it.
Kenneth Adam Miller <kennethadammiller@gmail.com> writes:
> Well, maybe I'm understanding that wrong. I am talking the cache that the tcg keeps of translated code. If I got that variable wrong then
> please let me know.
TB_JMP_CACHE_SIZE is used to keep a lookup of address to translated
blocks (TBs). This is used to find the next TB on a computed jump
without doing a full lookup in the QHT hash.
The total size of the translation cache is tb-size in MBs (as in -accel
tcg,tb-size=1024). We have some heuristics to guess at a size (see
DEFAULT_CODE_GEN_BUFFER_SIZE in tcg/region.c) but you are free to
specify your own.
> But I want to make sure that that is large enough to keep from having
> to run TCG again. How can I do that?
Specifying a large tb-size will reduce the churn caused by running out
of translation cache but you will never be able to eliminate it
entirely. There are a number of places where tb_flush() has to get
called and that will require stuff to get re-translated. Also the
translator partitions the regions up per-CPU (for softmmu) so if one
vCPU is responsible for all code generation it will run out sooner.
You can observe the total number of flushes via the HMP and "info jit".
What is the behaviour your seeing? What workload is it?
>
> On Wed, Sep 22, 2021, 6:54 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Kenneth Adam Miller <kennethadammiller@gmail.com> writes:
>
> > Hello all,
> >
> > I just want to ask this one question: if I change the qemu tcg cache
> > size (TB_JMP_CACHE_SIZE), will that force any errors at run time?
>
> Hopefully not - for both user-mode and softmmu we take some care to
> ensure tb_jmp_cache_hash_func and tb_jmp_cache_hash_page return
> appropriately masked values for the table lookup.
>
> What has not been done since Emilio's work in 6f1653180f (tb-hash:
> improve tb_jmp_cache hash function in user mode) is a deeper look at the
> hit rate and bounce rate of the softmmu jump table hashing. Any
> suggested changes will need some benchmarking to show what difference it
> makes.
>
> --
> Alex Bennée
--
Alex Bennée