kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: "Nadav Har'El" <nyh@math.technion.ac.il>
Cc: kvm@vger.kernel.org, mst@redhat.com, abelg@il.ibm.com
Subject: Re: [PATCH] vhost: don't forget to schedule()
Date: Tue, 28 Feb 2012 16:29:10 +0200	[thread overview]
Message-ID: <4F4CE4B6.5020407@redhat.com> (raw)
In-Reply-To: <20120228140020.GA8903@fermat.math.technion.ac.il>

On 02/28/2012 04:00 PM, Nadav Har'El wrote:
> On Tue, Feb 28, 2012, Avi Kivity wrote about "Re: [PATCH] vhost: don't forget to schedule()":
> > > +			if (need_resched())
> > > +				schedule();
> > 
> > This is cond_resched(), no?
>
> It indeed looks similar, but it appears there are some slightly
> different things happening in both cases, especially for a preemptive
> kernel... Unfortunately, I am not astute (or experienced) enough to tell 
> which of the two idioms are better or more appropriate for this case.

I'd have expected that cond_resched() is a no-op with preemptible
kernels, but I see this is not the case.

>
> The idiom that I used seemed right, and seemed to work in my tests.
> Moreover I also noticed it was used in vmx.c. Also, vhost.c was already
> calling schedule(), not cond_resched(), so I thought it made sense to
> call the same thing...
>
> But I now see that in kvm_main.c, there's also this:
>
>         if (!need_resched())
>                 return;
>         cond_resched();
>
> Which seems to combine both idioms ;-) Can anybody shed a light on what
> is the right way to do it?
>

It's bogus.  Look at commit 3fca03653010:

Author: Yaozu Dong <eddie.dong@intel.com>
Date:   Wed Apr 25 16:49:19 2007 +0300

    KVM: VMX: Avoid unnecessary vcpu_load()/vcpu_put() cycles
   
    By checking if a reschedule is needed, we avoid dropping the vcpu.
   
    [With changes by me, based on Anthony Liguori's observations]
   
    Signed-off-by: Avi Kivity <avi@qumranet.com>

diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 03c0ee7..f535635 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1590,6 +1590,8 @@ static int set_msr(struct kvm_vcpu *vcpu, u32
msr_index, u64 data)
 
 void kvm_resched(struct kvm_vcpu *vcpu)
 {
+       if (!need_resched())
+               return;
        vcpu_put(vcpu);
        cond_resched();
        vcpu_load(vcpu);

at that time, it made sense to do the extra check to avoid the expensive
vcpu_put/vcpu_load.  Later preempt notifiers made them redundant
(15ad71460d75), and they were removed, but the extra check remained.

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


  reply	other threads:[~2012-02-28 14:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-27 13:07 [PATCH] vhost: don't forget to schedule() Nadav Har'El
2012-02-28 13:07 ` Avi Kivity
2012-02-28 14:00   ` Nadav Har'El
2012-02-28 14:29     ` Avi Kivity [this message]
2012-03-04  9:10       ` Nadav Har'El
2012-03-04  9:16         ` Michael S. Tsirkin
2012-03-18 13:55           ` Nadav Har'El

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F4CE4B6.5020407@redhat.com \
    --to=avi@redhat.com \
    --cc=abelg@il.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=nyh@math.technion.ac.il \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).