Re: [Qemu-devel] [PATCH v4 1/5] cpu: Provide vcpu throttling interface

[Paolo Bonzini <pbonzini@redhat.com>]

On 16/07/2015 16:21, Jason J. Herne wrote:
> 1. Using atomic operations to manage throttle_percentage. I'm not sure
> where atomics are applicable here. If this is still a concern hopefully
> someone can explain.

I would use atomic_read/atomic_set in cpu_throttle_set, 
cpu_throttle_stop, cpu_throttle_active, cpu_throttle_get_percentage.  
In addition, the function naming seems to be a bit inconsistent: please 
rename cpu_throttle_set to cpu_throttle_set_percentage.

Second, here:

>> +static void cpu_throttle_thread(void *opaque)
>> +{
>> + double pct = (double)throttle_percentage/100;

Please use cpu_throttle_get_percentage(), and

>> + double throttle_ratio = pct / (1 - pct);
>> + long sleeptime_ms = (long)(throttle_ratio * CPU_THROTTLE_TIMESLICE);

... move these computations below the if.

I'm also not sure about throttle_ratio, why is it needed?  If pct >= 0.5 you
end up with throttle_ratio >= 1, i.e. no way for the CPU to do any work.  This
would definitely cause a problem with callbacks piling up.

>> + if (!throttle_percentage) {
>> + return;
>> + }
>> +
>> + qemu_mutex_unlock_iothread();
>> + g_usleep(sleeptime_ms * 1000); /* Convert ms to us for usleep call */
>> + qemu_mutex_lock_iothread();
>> +}
>> +

> 2. Callback stacking. And it seems like we are convinced that it is not
> a big issue. Anyone disagree?

I think it's not a big issue to have many timers, but it is a big issue to have many callbacks.  What I suggested is this:

    if (!atomic_xchg(&cpu->throttle_thread_scheduled, 1)) {
        async_run_on_cpu(cpu, cpu_throttle_thread, NULL);
    }

and in the callback:

    atomic_set(&cpu->throttle_thread_scheduled, 0);
    g_usleep(...); 

Paolo