Re: [PATCH RFC 1/1] kvm: Use vcpu_id as pivot instead of last boosted vcpu in PLE handler

2012-09-14 Thread Raghavendra K T
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

Re: [PATCH RFC 1/1] kvm: Use vcpu_id as pivot instead of last boosted vcpu in PLE handler

2012-09-14 Thread Raghavendra K T
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

Re: [PATCH RFC 1/1] kvm: Use vcpu_id as pivot instead of last boosted vcpu in PLE handler

2012-09-04 Thread Raghavendra K T
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

Re: [PATCH RFC 1/1] kvm: Use vcpu_id as pivot instead of last boosted vcpu in PLE handler

2012-09-04 Thread Raghavendra K T
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

Re: [PATCH RFC 1/1] kvm: Use vcpu_id as pivot instead of last boosted vcpu in PLE handler

2012-09-02 Thread Rik van Riel
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

Re: [PATCH RFC 1/1] kvm: Use vcpu_id as pivot instead of last boosted vcpu in PLE handler

2012-09-02 Thread Gleb Natapov
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

Re: [PATCH RFC 1/1] kvm: Use vcpu_id as pivot instead of last boosted vcpu in PLE handler

2012-09-02 Thread Gleb Natapov
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

Re: [PATCH RFC 1/1] kvm: Use vcpu_id as pivot instead of last boosted vcpu in PLE handler

2012-09-02 Thread Rik van Riel
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

[PATCH RFC 1/1] kvm: Use vcpu_id as pivot instead of last boosted vcpu in PLE handler

2012-08-29 Thread Raghavendra K T
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

[PATCH RFC 1/1] kvm: Use vcpu_id as pivot instead of last boosted vcpu in PLE handler

2012-08-29 Thread Raghavendra K T
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