From: Avi Kivity <avi@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Mark Langsdorf <mark.langsdorf@amd.com>,
Joerg Roedel <joerg.roedel@amd.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM
Date: Mon, 11 May 2009 17:24:57 +0300 [thread overview]
Message-ID: <4A083539.407@redhat.com> (raw)
In-Reply-To: <20090511141503.GC6175@elte.hu>
Ingo Molnar wrote:
>
>>> +static int pause_interception(struct vcpu_svm *svm, struct kvm_run
>>> *kvm_run)
>>> +{
>>> + /* Simple yield */
>>> + vcpu_put(&svm->vcpu);
>>> + schedule();
>>> + vcpu_load(&svm->vcpu);
>>> + return 1;
>>> +
>>>
>> Ingo, will this do anything under CFS, or will CFS note that
>> nothing has changed in the accounting and reschedule us
>> immediately?
>>
>
> The scheduler will yield to another task only if the current task
> has become ineligible. I.e schedule() is largely a NOP on
> TASK_RUNNING tasks (i.e. here).
>
Especially on preemptible kernels, where the schedule() would have
already happened if it could cause anything, IIUC.
> I.e. this is a somewhat poor solution as far as scheduling goes. But
> i'm wondering what the CPU side does. Can REP-NOP really take
> thousands of cycles? If yes, under what circumstances?
>
The guest is running rep-nop in a loop while trying to acquire a
spinlock. The hardware detects this (most likely, repeated rep-nop with
the same rip) and exits. We can program the loop count; obviously if
we're spinning for only a short while it's better to keep spinning while
hoping the lock will be released soon.
The idea is to detect that the guest is not making forward progress and
yield. If I could tell the scheduler, you may charge me a couple of
milliseconds, I promise not to sue, that would be ideal. Other tasks
can become eligible, hopefully the task holding the spinlock, and by the
time we're scheduled back the long running task will have finished and
released the lock.
For newer Linux as a guest we're better off paravirtualizing this, so we
can tell the host which vcpu holds the lock; in this case kvm will want
to say, take a couple milliseconds off my account and transfer it to
this task (so called directed yield). However there's no reason to
paravirtualize all cpu_relax() calls.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2009-05-11 14:25 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-05 14:09 [PATCH][KVM] Add support for Pause Filtering to AMD SVM Mark Langsdorf
2009-05-05 16:05 ` Bert Wesarg
2009-05-07 13:55 ` Joerg Roedel
2009-05-07 15:00 ` [PATCH][KVM][retry 1] " Mark Langsdorf
2009-05-07 15:31 ` Avi Kivity
2009-05-11 14:15 ` Ingo Molnar
2009-05-11 14:24 ` Avi Kivity [this message]
2009-05-11 14:33 ` Ingo Molnar
2009-05-11 14:51 ` Avi Kivity
2009-05-11 14:59 ` Ingo Molnar
2009-05-11 15:12 ` Avi Kivity
2009-05-11 15:18 ` Ingo Molnar
2009-05-11 15:28 ` Avi Kivity
2009-05-11 15:36 ` Langsdorf, Mark
2009-05-11 15:40 ` Avi Kivity
2009-05-11 15:58 ` [PATCH][KVM][retry 1] Add support for Pause Filtering to AMDSVM Langsdorf, Mark
2009-05-11 15:01 ` [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM Peter Zijlstra
2009-05-11 15:06 ` Avi Kivity
2009-05-11 14:42 ` Peter Zijlstra
2009-05-11 15:05 ` Avi Kivity
2009-05-08 17:03 ` [PATCH][KVM][retry 2] " Mark Langsdorf
2009-05-08 18:44 ` Avi Kivity
2009-05-08 18:47 ` Langsdorf, Mark
2009-05-19 18:56 ` [PATCH][KVM][retry 3] " Mark Langsdorf
2009-05-20 7:40 ` Ingo Molnar
2009-05-20 7:59 ` Peter Zijlstra
2009-05-20 8:38 ` Avi Kivity
2009-05-20 8:42 ` Peter Zijlstra
2009-05-20 8:49 ` Avi Kivity
2009-05-20 8:54 ` Peter Zijlstra
2009-05-20 9:04 ` Avi Kivity
2009-05-20 9:10 ` Peter Zijlstra
2009-05-20 9:17 ` Avi Kivity
2009-05-20 13:52 ` Langsdorf, Mark
2009-05-20 12:00 ` Avi Kivity
2009-05-20 22:25 ` [PATCH][KVM][retry 4] " Mark Langsdorf
2009-05-21 8:47 ` Avi Kivity
2009-07-08 5:19 ` Sheng Yang
2009-07-08 14:59 ` Langsdorf, Mark
2009-07-09 1:50 ` Sheng Yang
2009-07-22 22:40 ` Langsdorf, Mark
2009-08-05 9:08 ` Zhai, Edwin
2009-05-11 14:38 ` [PATCH][KVM] " Peter Zijlstra
2009-05-11 14:51 ` Ingo Molnar
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=4A083539.407@redhat.com \
--to=avi@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=joerg.roedel@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.langsdorf@amd.com \
--cc=mingo@elte.hu \
/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).