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

[Evgeny Voevodin <e.voevodin@samsung.com>]

On 01.03.2012 12:27, Peter Maydell wrote:
> On 1 March 2012 08:22, Andreas Färber<afaerber@suse.de>  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: e.voevodin@samsung.com