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. On Wed, Sep 22, 2021 at 1:39 PM Alex Bennée <alex.ben...@linaro.org> wrote: > > Kenneth Adam Miller <kennethadammil...@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.ben...@linaro.org> > wrote: > > > > Kenneth Adam Miller <kennethadammil...@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 >
