On 09/02/2012 09:59 PM, Rik van Riel wrote:
On 09/02/2012 06:12 AM, Gleb Natapov wrote:
On Thu, Aug 30, 2012 at 12:51:01AM +0530, Raghavendra K T wrote:
The idea of starting from next vcpu (source of yield_to + 1) seem to
work
well for overcomitted guest rather than using last boosted vcpu. We
On 09/02/2012 09:59 PM, Rik van Riel wrote:
On 09/02/2012 06:12 AM, Gleb Natapov wrote:
On Thu, Aug 30, 2012 at 12:51:01AM +0530, Raghavendra K T wrote:
The idea of starting from next vcpu (source of yield_to + 1) seem to
work
well for overcomitted guest rather than using last boosted vcpu. We
On 09/02/2012 06:12 AM, Gleb Natapov wrote:
On Thu, Aug 30, 2012 at 12:51:01AM +0530, Raghavendra K T wrote:
The idea of starting from next vcpu (source of yield_to + 1) seem to work
well for overcomitted guest rather than using last boosted vcpu. We can also
remove per VM variable with th
On Thu, Aug 30, 2012 at 12:51:01AM +0530, Raghavendra K T wrote:
> The idea of starting from next vcpu (source of yield_to + 1) seem to work
> well for overcomitted guest rather than using last boosted vcpu. We can also
> remove per VM variable with this approach.
>
> Iteration for eligible c
The idea of starting from next vcpu (source of yield_to + 1) seem to work
well for overcomitted guest rather than using last boosted vcpu. We can also
remove per VM variable with this approach.
Iteration for eligible candidate after this patch starts from vcpu source+1
and ends at source-1 (