qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] TCG: Convert global variables to be TLS.


From: Evgeny Voevodin
Subject: Re: [Qemu-devel] [PATCH v2] TCG: Convert global variables to be TLS.
Date: Thu, 01 Mar 2012 14:57:18 +0400
User-agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

On 01.03.2012 12:27, Peter Maydell wrote:
On 1 March 2012 08:22, Andreas Färber<address@hidden>  wrote:
Am 28.02.2012 04:13, schrieb Evgeny Voevodin:
On 27.02.2012 16:35, Peter Maydell wrote:
A true multithreaded TCG is a large project, and unless we're
going to commit to doing that I don't see much value in making
some variables per-thread when we might instead need to do
larger refactorings (properly encapsulating the codegen
caches as qom objects, maybe?).
[...] qomification of translation caches is an interesting suggestion I
think.
While I have come to like QOM and am using it for the CPUState, I don't
see the benefit in using it for these secondary structures. There are
already dedicated monitor commands to inspect them, no?
Mostly I was thinking about the encapsulation of knowing which data
structures are associated with a translation cache and letting you
have more than one of them. You could do that with a plain struct
but since we have this OO infrastructure now why not use it?

-- PMM


Actually, I didn't dive deep enough in QOM and can't see any benefits or disadvantages in such encapsulation. As stands to me now, QOM is mostly an interface, but internal things are still structs :) And if we implement appropriate model for multithreading TCG, I believe,
that it could be easily wrapped with QOM, if needed.
Also, there are at least two approaches for cache - unified for all VCPUs and exclusive for each VCPU. First is better when a lot of different threads run in the target, since each cache holds
unique code and thread communication is small.
Second is better when a lot of identical threads running since no excessive translation of identical code is made by each VCPU thread, but communication between threads on accessing the cache is high. So, what I'm talking about is if we use unified cache, we may not need to have more than one cache instance.

--
Kind regards,
Evgeny Voevodin,
Leading Software Engineer,
ASWG, Moscow R&D center, Samsung Electronics
e-mail: address@hidden





reply via email to

[Prev in Thread] Current Thread [Next in Thread]