|
From: | Jason J. Herne |
Subject: | Re: [Qemu-devel] [PATCH v4 1/5] cpu: Provide vcpu throttling interface |
Date: | Fri, 31 Jul 2015 14:11:23 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 |
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. PaoloDoh! 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 (address@hidden)
[Prev in Thread] | Current Thread | [Next in Thread] |