> On 25 May 2017, at 16:52, Paolo Bonzini <pbonz...@redhat.com> 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 <fel...@nutanix.com>
>> Signed-off-by: Malcolm Crossley <malc...@nutanix.com>


Reply via email to