Re: [Xen-devel] [PATCH v3] xen/arm: introduce vwfi parameter

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Tue, 2017-02-28 at 13:12 -0800, Stefano Stabellini wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1638,6 +1638,20 @@ Note that if **watchdog** option is also
> specified vpmu will be turned off.
>  As the virtualisation is not 100% safe, don't use the vpmu flag on
>  production systems (see http://xenbits.xen.org/xsa/advisory-163.html
> )!
>  
> +### vwfi
> +> `= trap | native
> +
> +> Default: `trap`
> +
> +WFI is the ARM instruction to "wait for interrupt". WFE is similar
> and
> +means "wait for event". This option, which is ARM specific, changes
> the
> +way guest WFI and WFE are implemented in Xen. By default, Xen traps
> both
> +instructions. In the case of WFI, Xen blocks the guest vcpu; in the
> case
> +of WFE, Xen yield the guest vcpu. When setting vwfi to `native`, Xen
> +doesn't trap either instruction, running them in guest context.
> Setting
> +vwfi to `native` reduces irq latency, but leads to suboptimal
> scheduling
> +decisions.
> +
These last few words sounds a bit generic to me. They may alarm people
and discourage using 'native', even when it is actually ok.

Being a bit more specific, although without going into too much
technical detail, seems worth to me.

So, how about something like:

"Using `native` reduces irq latency significantly. It can also lead to
suboptimal scheduling decisions and affect performance, but only when
the system is oversubscribed (i.e., there are, in total, more vCPUs
than pCPUs)."

?

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: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel