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
next prev parent 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).