On Mon, Nov 27, 2017 at 11:36:11PM +0100, Jan H. Schönherr wrote:
> On 11/27/2017 09:46 PM, Michael S. Tsirkin wrote:
> > On Sat, Nov 25, 2017 at 02:09:31PM +0100, Jan H. Schönherr wrote:
> >> Allowing a guest to execute MWAIT without interception enables a guest
> >> to put a (physical) CPU into a power saving state, where it takes
> >> longer to return from than what may be desired by the host.
> >>
> >> Don't give a guest that power over a host by default. (Especially,
> >> since nothing prevents a guest from using MWAIT even when it is not
> >> advertised via CPUID.)
> >>
> >> This restores the behavior from before Linux 4.12 commit 668fffa3f838
> >> ("kvm: better MWAIT emulation for guests") but keeps the option to
> >> enable MWAIT in guest for individual VMs.
> >
> > As others pointed out, an interrupt will wake up the host CPU anyway.
> >
> > Given that, what's the actual motivation here?
>
> The CPU will wake up, but it will take time depending which C-state the
> guest requested and achieved to enter.
>
> Since Linux 4.11 and 4.14 the menu and ladder cpuidle governors, respectively,
> allow setting a per CPU wakeup latency requirement -- see, eg, commit c523c68da211
> ("cpuidle: ladder: Add per CPU PM QoS resume latency support"). Allowing a guest
> to execute MWAIT without moderation will bypass that functionality.
>
> Thus, while MWAIT-in-guest is a great thing to have when there are dedicated
> CPUs, it is less so, when the CPUs still have to do other activities.
>
> Regards
> Jan
I see. And the example given there is a CPU running real time
applications.
If you do another version, it might be helpful to add
this info. E.g.
"... than desired by the host - e.g. when the same CPU is running
another real time applications".
I wonder how well does it work to mix real time apps
and VMs on the same CPU.
--
MST
