lkml.org 
[lkml]   [2012]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC V6 0/11] Paravirtualized ticketlocks
On 04/02/2012 12:51 PM, Raghavendra K T wrote:
> On 04/01/2012 07:23 PM, Avi Kivity wrote:
> > On 04/01/2012 04:48 PM, Raghavendra K T wrote:
> >>>> I have patch something like below in mind to try:
> >>>>
> >>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> >>>> index d3b98b1..5127668 100644
> >>>> --- a/virt/kvm/kvm_main.c
> >>>> +++ b/virt/kvm/kvm_main.c
> >>>> @@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
> >>>> * else and called schedule in __vcpu_run. Hopefully that
> >>>> * VCPU is holding the lock that we need and will release it.
> >>>> * We approximate round-robin by starting at the last boosted
> >>>> VCPU.
> >>>> + * Priority is given to vcpu that are unhalted.
> >>>> */
> >>>> - for (pass = 0; pass< 2&& !yielded; pass++) {
> >>>> + for (pass = 0; pass< 3&& !yielded; pass++) {
> >>>> kvm_for_each_vcpu(i, vcpu, kvm) {
> >>>> struct task_struct *task = NULL;
> >>>> struct pid *pid;
> >>>> - if (!pass&& i< last_boosted_vcpu) {
> >>>> + if (!pass&& !vcpu->pv_unhalted)
> >>>> + continue;
> >>>> + else if (pass == 1&& i< last_boosted_vcpu) {
> >>>> i = last_boosted_vcpu;
> >>>> continue;
> >>>> - } else if (pass&& i> last_boosted_vcpu)
> >>>> + } else if (pass == 2&& i> last_boosted_vcpu)
> >>>> break;
> >>>> if (vcpu == me)
> >>>> continue;
> >>>>
> >>>
> >>> Actually I think this is unneeded. The loops tries to find vcpus
> that
> >>> are runnable but not running (vcpu_active(vcpu->wq)), and halted
> vcpus
> >>> don't match this condition.
> >>>
>
> Oh! I think I misinterpreted your statement. hmm I got it. you told to
> remove if (vcpu == me) condition.

No, the entire patch is unneeded. My original comment was:

> from the PLE handler, don't wake up a vcpu that is sleeping because it
is waiting for a kick

But the PLE handler never wakes up sleeping vcpus anyway.

There's still a conflict with PLE in that it may trigger during the spin
phase and send a random yield_to() somewhere. Maybe it's sufficient to
tune the PLE timeout to be longer than the spinlock timeout.


--
error compiling committee.c: too many arguments to function



\
 
 \ /
  Last update: 2012-04-05 11:11    [W:0.133 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site