Richard Henderson <r...@twiddle.net> writes: > On 07/18/2017 02:22 PM, jiang.bi...@zte.com.cn wrote: >> Seeing your work on multiple TCG, it seems that it has some kind of >> connection with the MTTCG feature, >> >> but I do not figure out how they are connected in detail. >> >> Could you pls help to confirm the following questions: >> >> 1. >> >> what is the relationship between your patches and the MTTCG feature >> mentioned by https://lwn.net/Articles/697265/? > > > The current MTTCG feature is in QEMU mainline. It allows parallel > execution of translated code in both system mode. It does *not* allow > parallel translation -- all translation is done with tb_lock held. > > Note that we *always* have parallel execution in user mode. However, > this can and does lead to problems. See below. > > This patch set allows parallel translation in system mode. This is > shown to improve the overall throughput. It does *not* allow parallel > translation in user mode. Firstly because user mode already shares > more translations between threads (because it is running a single > executable), and so the translation routines are not high in the > profile. Secondly because there are additional locking problems due > to the fact that we have no bound on the number of user threads. > > >> 2. >> >> What is the current status of the development of the MTTCG feature? > > MTTCG has only been enabled on a few targets: alpha, arm, ppc64. > Look for "mttcg=yes" in configure. > > In order for MTTCG to be enabled, the target must be adjusted so that > (1) all atomic instructions are implemented with atomic tcg operations, > (2) define TCG_GUEST_DEFAULT_MO to indicate any barriers implied by > normal memory operations by the target architecture. > > For target/mips, neither of these things are complete. > > MTTCG has only been enabled on one host: i386. > Look for TCG_TARGET_DEFAULT_MO in tcg/*/tcg-target.h. > > In order for MTTCG to be enabled, the target memory order must not be > stronger than the host memory order. Since i386 has a very strong > host memory order, it is easy for it to emulate any guest. When the > host has a weak memory order, we need to add the additional barriers > that are implied by the target. This is work that has not been done. > > I am not sure why we have not already added this definition to all of > the other tcg hosts. I think this is just oversight, since almost > everyone uses x86_64 linux as the host for testing tcg. However, > since all of the supported targets have weak memory orders we ought to > be able to support them with any host.
Yeah the MO definitions can be added to the other guests/backends. I was hoping it would be done by those who have a better understanding of each guests micro-architecture so as to avoid any silly mistakes. As you say I think they will all mostly be 0 anyway ;-) >> 3. >> >> Is there any problem with the multithread programme running with >> linux-user >> qemu mode? would the situation be improved with the MTTCG feature? >> >> We need to use linux-user mode qemu to run multithread app, but there >> seems >> to be many problem. > > For user mode, we should still follow the rules for MTTCG, but we do > not. Instead we take it on faith that they have been and execute the > code in parallel anyway. This faith is often misplaced and it does > mean that unsupported targets execute user mode code incorrectly. Certainly for user-mode once the appropriate changes are made to atomic and barrier support instructions user-mode stability should improve (modulo unsupported/buggy syscall translation). System mode emulation usually requires a bit more work and system-wide instructions, usually ones which trigger interrupts and TLB flushes, to make sure they are done in a safe way. -- Alex Bennée
