On Mon, Aug 24, 2015 at 2:23 AM, Emilio G. Cota <c...@braap.org> wrote: > Hi all, > > Here is MTTCG code I've been working on out-of-tree for the last few months. > > The patchset applies on top of pbonzini's mttcg branch, commit ca56de6f. > Fetch the branch from: https://github.com/bonzini/qemu/commits/mttcg > > The highlights of the patchset are as follows: > > - The first 5 patches are direct fixes to bugs only in the mttcg > branch. > > - Patches 6-12 fix issues in the master branch. > > - The remaining patches are really the meat of this patchset. > The main features are: > > * Support of MTTCG for both user and system mode. > > * Design: per-CPU TB jump list protected by a seqlock, > if the TB is not found there then check on the global, RCU-protected > 'hash table' > (i.e. fixed number of buckets), if not there then grab lock, check again, > and if it's not there then add generate the code and add the TB to the > hash table. > > It makes sense that Paolo's recent work on the mttcg branch ended up > being almost identical to this--it's simple and it scales well. > > * tb_lock must be held every time code is generated. The rationale is > that most of the time QEMU is executing code, not generating it.
While this is indeed true for an ideal case, currently there are situations where it's not: running a g++ process under qemu-system-sparc64 the comparable amount of time is spent on executing and generating the code [1]. Does this lock imply the translation performance won't gain anything when emulating a single core machine on a multi-core one? Artyom 1. https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02194.html -- Regards, Artyom Tarasenko SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
