xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Dario Faggioli <dario.faggioli@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>,
	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: Tue, 21 Feb 2017 16:07:11 +0100	[thread overview]
Message-ID: <1487689631.6732.412.camel@citrix.com> (raw)
In-Reply-To: <6a7b800a-dd6a-15a2-665d-d28352f24cd1@citrix.com>


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

On Tue, 2017-02-21 at 13:46 +0000, George Dunlap wrote:
>
> A.  Don't trap guest WFI at all -- allow it to 'halt' in
> moderate-power-but-ready-for-interrupt mode.
> 
> [..]
>
> A is safe because the scheduler should already have set a timer to
> break
> out of it if necessary.  The only potential issue here is that the
> guest
> is burning its credits, meaning that other vcpus with something
> potentially useful to do aren't being allowed to run; and then later
> when this vcpu has something useful to do it may be prevented from
> running because of low credits.  (This may be what Dario means when
> he
> says it "breaks scheduling").
> 
Are you also referring to the case when there are less vCPUs around
than the host has pCPUs (and, ideally, all vCPUs are pinned 1:1 to a
pCPU)? If yes, I agree that we're probably fine, but we have to check
and enforce all this to be the case.

If no, think at a situation where there is 1 vCPU running on a pCPU and
3 vCPUs in the runqueue (it may be a per-CPU Credit1 runqueue or a
shared among some pCPUs Credit2 runqueue). If the running vCPU goes
idle, let's say with WFI, we _don't_ want the pCPU to enter neither
moderate nor deep sleep, we want to pick up the first of the 3 other
vCPUs that are waiting in the runqueue.

This is what I mean when I say "breaks scheduling". :-)

Oh, actually, if --which I only now realize may be what you are
referring to, since you're talking about "guest burning its credits"--
you let the vCPU put the pCPU to sleep *but*, when it wakes up (or when
the scheduler runs again for whatever reason), you charge to it for all
the time the the pCPU was actually idle/sleeping, well, that may
actually  not break scheduling, or cause disruption to the service of
other vCPUs.... But indeed I'd consider it rather counter intuitive a
behavior.

In fact, it'd mean that the guest has issued WFI because he wanted to
sleep and we do put it to sleep. But when it wakes up, we treat it like
it had busy waited.

What would be the benefit of this? That we don't context switch (either
to idle or to someone else)?

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-21 15:07 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 [this message]
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=1487689631.6732.412.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 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).