[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] cpus: reset throttle_thread_scheduled after sle
From: |
Felipe Franciosi |
Subject: |
Re: [Qemu-devel] [PATCH] cpus: reset throttle_thread_scheduled after sleep |
Date: |
Thu, 25 May 2017 16:25:07 +0000 |
> On 25 May 2017, at 16:52, Paolo Bonzini <address@hidden> wrote:
>
>
>
> On 19/05/2017 23:29, Felipe Franciosi wrote:
>> Currently, the throttle_thread_scheduled flag is reset back to 0 before
>> sleeping (as part of the throttling logic). Given that throttle_timer
>> (well, any timer) may tick with a slight delay, it so happens that under
>> heavy throttling (ie. close or on CPU_THROTTLE_PCT_MAX) the tick may
>> schedule a further cpu_throttle_thread() work item after the flag reset,
>> but before the previous sleep completed. This results on the vCPU thread
>> sleeping continuously for potentially several seconds in a row.
>>
>> The chances of that happening can be drastically minimised by resetting
>> the flag after the sleep.
>
> True, on the other hand this may also increase the chance of not
> sleeping at all.
The perfect solution (for this throttling strategy) would probably be a per-cpu
timer. In the meantime, I think avoiding massive sleeps is a win. We observed
stalls in excess of 70 secs at 99% throttle.
> How overcommitted was the host system?
Not overcommitted at all. And it's quite easy to reproduce. All you need is a
workload heavy enough to prevent the migration from converging (or a slow
network which you can emulate with a qdisc).
With a Linux guest, you should quickly see soft lockups being reported. With
Windows, probably BSODs.
Thanks,
Felipe
>
> Paolo
>
>> Signed-off-by: Felipe Franciosi <address@hidden>
>> Signed-off-by: Malcolm Crossley <address@hidden>