On 02/07/16 03:17, Richard Henderson wrote:
> On 06/27/2016 02:20 PM, Sergey Fedorov wrote:
>> On 03/06/16 23:40, Alex Bennée wrote:
>>> diff --git a/cpus.c b/cpus.c
>>> index 1694ce9..12e04c9 100644
>>> --- a/cpus.c
>>> +++ b/cpus.c
>>> @@ -1208,9 +1208,29 @@ static int tcg_cpu_exec(CPUState *cpu)
>>> return ret;
>>> }
>>>
>>> +/* Single-threaded TCG
>>> + *
>>> + * In the single-threaded case each vCPU is simulated in turn. If
>>> + * there is more than a single vCPU we create a simple timer to kick
>>> + * the vCPU and ensure we don't get stuck in a tight loop in one vCPU.
>>> + * This is done explicitly rather than relying on side-effects
>>> + * elsewhere.
>>> + */
>>> +static void qemu_cpu_kick_no_halt(void);
>>> +#define TCG_KICK_FREQ (qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + \
>>> + NANOSECONDS_PER_SECOND / 10)
>>
>> Hmm, it doesn't look nice to wrap calculation of the next timeout in a
>> macro and name it '*_FREQ'. I think we'd better do like this:
>>
>> #define TCG_KICK_PERIOD (NANOSECONDS_PER_SECOND / 10)
>>
>> static inline int64_t qemu_tcg_next_kick(void)
>> {
>> return qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + TCG_KICK_PERIOD;
>> }
>>
>> and use it like this:
>>
>> timer_mod(kick_timer, qemu_tcg_next_kick());
>
> Agreed.
>
> As an aside, surely a period of 10ns is too small.
> That's on the order of 20-50 host instructions.
I think the period is 10 times in a second which is 100 ms.
Regards,
Sergey
