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

["Jason J. Herne" <jjherne@linux.vnet.ibm.com>]

On 07/31/2015 01:42 PM, Jason J. Herne wrote:
> On 07/31/2015 01:16 PM, Paolo Bonzini wrote:
>>
>>
>> On 31/07/2015 19:12, Jason J. Herne wrote:
>>>>
>>>>
>>>
>>> Throttle ratio is relative to CPU_THROTTLE_TIMESLICE. Take a look at how
>>> throttle_ratio is used in the calculation:
>>>
>>> long sleeptime_ms = (long)(throttle_ratio * CPU_THROTTLE_TIMESLICE);
>>>
>>> A value of 1 means we sleep the same amount of time that we execute.
>>
>> But that doesn't work if your timer runs every CPU_THROTTLE_TIMESLICE
>> milliseconds, and thus schedules async work every CPU_THROTTLE_TIMESLICE
>> milliseconds.
>>
>> The timer would have to be scheduled every (throttle_ratio + 1) *
>> CPU_THROTTLE_TIMESLICE milliseconds, i.e. CPU_THROTTLE_TIMESLICE /
>> (1-pct) milliseconds.
>>
>> Paolo
>
> Doh! Yep :). This problem is an artifact of moving the timer_mod from
> cpu_throttle_thread into cpu_throttle_timer_tick. I'll have to go back
> to the review comments and look at why that was done.

So, we made that change in v3 to eliminate the per cpu timer. With a per
cpu timer we avoid this problem and we no longer need to worry about
a throttle_thread_scheduled, and timers stacking. Paolo, you had originally
argued in favor of this change. With what we know now, do you still think
having only a single timer is best? Or should I switch back to a timer per
cpu? With a timer per cpu we can simply reset the timer immediately after
the sleep.

I guess an alternative would be for the last cpu to complete its sleep to
reset the timer in cpu_throttle_thread. We would need an atomic flag in
CPUState and a loop to run it and bail out if any cpu has the flag set.

-- 
-- Jason J. Herne (jjherne@linux.vnet.ibm.com)