From: Ingo Molnar <mingo@elte.hu>
To: Avi Kivity <avi@redhat.com>
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 16:59:03 +0200 [thread overview]
Message-ID: <20090511145903.GB737@elte.hu> (raw)
In-Reply-To: <4A083B69.6010702@redhat.com>
* Avi Kivity <avi@redhat.com> wrote:
>> And only do it if there's other tasks running on this CPU or so.
>
> What would happen if there weren't? I'd guess the task would
> continue running (but with a warped vruntime)?
We dont want that warping to occur - we just want to go back and
burn CPU time in VM context. The problem is (as Peter pointed it
out) that this hw facility is incomplete and does not give us any
event (interrupt) and does not give us any event key (address we are
waiting for) either.
So the next best thing to do is to go back to the guest, because
that is where we make the most progress, more likely, and that is
where we want to be to make progress immediately, with the shortest
latency.
( Perhaps we could also increase vruntime beyond the standard
latency value to make sure any freshly woken task gets executed
first if we are still looping. )
>> _That_ would be pretty efficient, and would do the right thing when
>> two (or more) vcpus run on the same CPU, and it would also do the
>> right thing if there are repeated VM-exits due to pause filtering.
>>
>> Please dont even think about using yield for this though - that will
>> just add a huge hit to this task and wont result in any sane behavior -
>> and yield is bound to some historic user-space behavior as well.
>>
>> A gradual and linear back-off from the current timeline is more of a
>> fair negotiation process between vcpus and results in more or less
>> sane (and fair) scheduling, and no unnecessary looping.
>>
>> You could even do an exponential backoff up to a limit of 1-10 msecs
>> or so, starting at 100 usecs.
>>
>
> Good idea, it eliminates another variable to be tuned.
It could be made fully self-tuning, if the filter threshold can be
tuned fast enough. (an MSR write? A VM context field update?)
I.e. the 3000 cycles value itself could be eliminated as well. (with
just a common-sense max of say 100,000 cycles enforced)
Ingo
next prev parent reply other threads:[~2009-05-11 14:59 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-05 14:09 [PATCH][KVM] " 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
2009-05-11 14:33 ` Ingo Molnar
2009-05-11 14:51 ` Avi Kivity
2009-05-11 14:59 ` Ingo Molnar [this message]
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=20090511145903.GB737@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=avi@redhat.com \
--cc=joerg.roedel@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.langsdorf@amd.com \
/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
all inboxes | Powered by JetHome®