During migrations, after each iteration, cpu_throttle_set() is called,
which irrespective of input, re-arms the timer according to value of
new_throttle_pct. This causes cpu_throttle_thread() to be delayed in
getting scheduled and consqeuntly lets guest run for more time than what
the throttle value should allow. This leads to spikes in guest throughput
at high cpu-throttle percentage whenever cpu_throttle_set() is called.
A solution would be not to modify the timer immediately in
cpu_throttle_set(), instead, only modify throttle_percentage so that the
throttle would automatically adjust to the required percentage when
cpu_throttle_timer_tick() is invoked.
Manually tested the patch using following configuration:
Guest:
Centos7 (3.10.0-123.el7.x86_64)
Total Memory - 64GB , CPUs - 16
Tool used - stress (1.0.4)
Workload - stress --vm 32 --vm-bytes 1G --vm-keep
Migration Parameters:
Network Bandwidth - 500MBPS
cpu-throttle-initial - 99
Results:
With timer_mod(): fails to converge, continues indefinitely
Without timer_mod(): converges in 249 sec
Signed-off-by: Utkarsh Tripathi <[email protected]>
Message-Id: <
1609420384[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
void cpu_throttle_set(int new_throttle_pct)
{
+ /*
+ * boolean to store whether throttle is already active or not,
+ * before modifying throttle_percentage
+ */
+ bool throttle_active = cpu_throttle_active();
+
/* Ensure throttle percentage is within valid range */
new_throttle_pct = MIN(new_throttle_pct, CPU_THROTTLE_PCT_MAX);
new_throttle_pct = MAX(new_throttle_pct, CPU_THROTTLE_PCT_MIN);
qatomic_set(&throttle_percentage, new_throttle_pct);
- timer_mod(throttle_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL_RT) +
- CPU_THROTTLE_TIMESLICE_NS);
+ if (!throttle_active) {
+ cpu_throttle_timer_tick(NULL);
+ }
}
void cpu_throttle_stop(void)