Also, that command flag was *really really buried, and I couldn't find it at all in the help. On Wed, Sep 22, 2021 at 1:50 PM Kenneth Adam Miller < kennethadammiller@gmail.com> wrote: > 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 > wrote: > >> >> Kenneth Adam Miller 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 >> wrote: >> > >> > Kenneth Adam Miller 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 >> >