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 (jjhe...@linux.vnet.ibm.com)
