xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Julien Grall <julien.grall@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: edgar.iglesias@xilinx.com, george.dunlap@eu.citrix.com,
	nd@arm.com, Punit Agrawal <punit.agrawal@arm.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/arm: introduce vwfi parameter
Date: Mon, 20 Feb 2017 20:20:36 +0100	[thread overview]
Message-ID: <1487618436.6732.230.camel@citrix.com> (raw)
In-Reply-To: <dc0a61ab-3dfc-89b8-42ce-a97eca30a3ec@arm.com>


[-- Attachment #1.1: Type: text/plain, Size: 2067 bytes --]

On Mon, 2017-02-20 at 18:53 +0000, Julien Grall wrote:
> On 20/02/17 18:47, Stefano Stabellini wrote:
> > This is a good question, I have already answered: I think it would
> > break
> > the scheduler. Dario confirmed it in his reply
> > (1487382463.6732.146.camel@citrix.com).
> 
> I don't think it will break the scheduler, we are trapping WFI/WFE
> to 
> take advantage of the quiescence of the guest. If we don't do that,
> the 
> guest will just waste his slot.
> 
Err... Wait... WF* basically puts a _pCPU_ to sleep until something
happens (interrupt or event). This is not something we let a guest
_vCPU_ do!

E.g., if vCPU x of domain A wants to go idle with a WFI/WFE, but the
host is overbooked and currently really busy, Xen wants to run some
other vCPU (of either the same of another domain).

That's actually the whole point of virtualization, and the reason why
overbooking an host with more vCPUs (from multiple guests) than it has
pCPUs works at all. If we start letting guests put the host's pCPUs to
sleep, not only the scheduler, but many things would break, IMO!

> Even if the WFI is done by the guest, you will receive the scheduler 
> interrupt in Xen and that's fine. Did I miss anything?
> 
Maybe it's me that am missing what you actually mean here.

What do you mean with "you will receive the scheduler interrupt"? Right
now, HLT in guest means block in Xen, which makes the scheduler run and
decide whether the pCPU should stay idle, or run someone else. I'd say
that no good can come from having HTL in guest automatically meaning
also on the pCPU.

So, I'm not sure what we're talking about, but what I'm quite sure is
that we don't want a guest to be able to decide when and until what
time/event, a pCPU goes idle.

Regards,
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

  reply	other threads:[~2017-02-20 19:20 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 [this message]
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
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=1487618436.6732.230.camel@citrix.com \
    --to=dario.faggioli@citrix.com \
    --cc=edgar.iglesias@xilinx.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 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).