qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] MTTCG Tasks (kvmforum summary)


From: Mark Burton
Subject: Re: [Qemu-devel] MTTCG Tasks (kvmforum summary)
Date: Fri, 4 Sep 2015 14:46:25 +0200

> On 4 Sep 2015, at 14:38, Lluís Vilanova <address@hidden> wrote:
> 
> dovgaluk  writes:
> 
>> Hi!
>> Alex Bennée писал 2015-09-04 10:49:
>>> * What to do about icount?
>>> 
>>> What is the impact of multi-thread on icount? Do we need to disable it
>>> for MTTCG or can it be correct per-cpu? Can it be updated lock-step?
> 
>> Why can't we have separate icount for each CPU?
>> Then virtual timer will be assigned to one of them.
> 
> My understanding is that icount means by deasign that time should be
> synchronized between cpus, where the number of executed instructions is the 
> time
> unit. If all elements worked under this assumption (I'm afraid that's not the
> case for I/O devices), it should be possible to reproduce executions by 
> setting
> icount to 1.
> 
> Now, MTTCG faces the same icount accuracy problems that the current TCG
> implementation deals with (only at different scale). The naive implementation 
> is
> to execute 1 instruction per CPU in lockstep. TCG currently relaxes this at 
> the
> translation block level.
> 
> The MTTCG implementation could do something similar, but just at a different
> (configurable?) granularity. Every N per-cpu instructions, synchronize all 
> CPUs
> until each has, at least, arrived at that time step, then proceed with the 
> next
> batch. Ideally, this synchronization delay (N) could be adapted dynamically.

This is often called a Quantum.

Cheers
Mark

> 
> My half cent.
> 
> Lluis
> 
> -- 
> "And it's much the same thing with knowledge, for whenever you learn
> something new, the whole world becomes that much richer."
> -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
> Tollbooth


         +44 (0)20 7100 3485 x 210
+33 (0)5 33 52 01 77x 210

        +33 (0)603762104
        mark.burton







reply via email to

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