From: Dario Faggioli <dario.faggioli@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>,
Stefano Stabellini <sstabellini@kernel.org>
Cc: edgar.iglesias@xilinx.com, george.dunlap@eu.citrix.com,
Punit Agrawal <punit.agrawal@arm.com>,
Julien Grall <julien.grall@arm.com>,
xen-devel@lists.xenproject.org, nd@arm.com
Subject: Re: [PATCH] xen/arm: introduce vwfi parameter
Date: Wed, 22 Feb 2017 17:40:00 +0100 [thread overview]
Message-ID: <1487781600.6732.436.camel@citrix.com> (raw)
In-Reply-To: <fb977604-2198-6ecb-dc05-927fe3d26eaa@citrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 2161 bytes --]
On Tue, 2017-02-21 at 18:17 +0000, George Dunlap wrote:
> On 21/02/17 17:49, Stefano Stabellini wrote:
> > I don't know the inner working of the scheduler, but does it always
> > send
> > an interrupt to other pcpu to schedule something?
>
> Letting a guest call WFI is as safe as letting a guest
> `while(1);`. Xen
> *always* has to set a timer interrupt before switching to the guest
> context to make sure that it can pre-empt the vcpu -- otherwise any
> vcpu
> could perform a DoS by simply continually executing instructions.
>
Yes, ensuring preemption happens is indeed Xen responsibility, and it
will indeed happen, as far as interrupts are enabled, as George says.
> > What if there are 2 vcpu pinned to the same pcpu? This cannot be
> > fair.
>
> From the scheduler's perspective, the WFI would be the same as the
> `while(1)`.
>
It is, provided you charge the vCPU for the time it spent in WFI, the
same as you'd charge it for time spend in a `while(1)`. This is
*probably* what happens already if we let WFI run on hardware, but I'd
double check and test.
> If you had two vcpus doing while(1) on the same vcpu, the
> credit2 scheduler would (approximately) let one run for 2ms, then the
> other for 2ms, and so on, each getting 50%.
>
If you're talking about MAX_TIMER, it's 10ms these days. But yes, this
still means 50% each.
> If ARM had the equivalent of posted interrupts, then a pinned guest
> could efficiently wait for interrupts with no additional latency from
> virtualization without having to poll.
>
> (Speaking of which -- that could be an interesting optimization even
> on
> x86... if a pcpu has no vcpus waiting to run, then disable HLT exit.)
>
Sorry, this sounds interesting but I'm not sure I understand what you
mean (but let's not hijack this thread, maybe, and talk about it
somewhere else. :-)
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-02-22 16:44 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1487286292-29502-1-git-send-email-sstabellini@kernel.org>
[not found] ` <a271394a-6c76-027c-fb08-b3fe775224ba@arm.com>
2017-02-17 22:50 ` [PATCH] xen/arm: introduce vwfi parameter Stefano Stabellini
2017-02-18 1:47 ` Dario Faggioli
2017-02-19 21:27 ` Julien Grall
2017-02-20 10:43 ` George Dunlap
2017-02-20 11:15 ` Dario Faggioli
2017-02-19 21:34 ` Julien Grall
2017-02-20 11:35 ` Dario Faggioli
2017-02-20 18:43 ` Stefano Stabellini
2017-02-20 18:45 ` George Dunlap
2017-02-20 18:49 ` Stefano Stabellini
2017-02-20 18:47 ` Stefano Stabellini
2017-02-20 18:53 ` Julien Grall
2017-02-20 19:20 ` Dario Faggioli
2017-02-20 19:38 ` Julien Grall
2017-02-20 22:53 ` Dario Faggioli
2017-02-21 0:38 ` Stefano Stabellini
2017-02-21 8:10 ` Julien Grall
2017-02-21 9:24 ` Dario Faggioli
2017-02-21 13:04 ` Julien Grall
2017-02-21 7:59 ` Julien Grall
2017-02-21 9:09 ` Dario Faggioli
2017-02-21 12:30 ` Julien Grall
2017-02-21 13:46 ` George Dunlap
2017-02-21 15:07 ` Dario Faggioli
2017-02-21 17:49 ` Stefano Stabellini
2017-02-21 17:56 ` Julien Grall
2017-02-21 18:30 ` Stefano Stabellini
2017-02-21 19:20 ` Julien Grall
2017-02-22 4:21 ` Edgar E. Iglesias
2017-02-22 17:22 ` Stefano Stabellini
2017-02-23 9:19 ` Edgar E. Iglesias
2017-02-21 18:17 ` George Dunlap
2017-02-22 16:40 ` Dario Faggioli [this message]
2017-02-21 15:14 ` Julien Grall
2017-02-21 16:59 ` George Dunlap
2017-02-21 18:03 ` Stefano Stabellini
2017-02-21 18:24 ` Julien Grall
2017-02-21 16:51 ` Dario Faggioli
2017-02-21 17:39 ` Stefano Stabellini
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=1487781600.6732.436.camel@citrix.com \
--to=dario.faggioli@citrix.com \
--cc=edgar.iglesias@xilinx.com \
--cc=george.dunlap@citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=julien.grall@arm.com \
--cc=nd@arm.com \
--cc=punit.agrawal@arm.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.