> 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>
