Re: [Qemu-devel] [RFC 00/38] MTTCG: i386, user+system mode

[Artyom Tarasenko]

On Mon, Aug 24, 2015 at 2:23 AM, Emilio G. Cota <address@hidden> 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