Peter Hessler <phess...@openbsd.org> writes:

> On 2018 Feb 26 (Mon) at 18:52:34 -0800 (-0800), Pratik Vyas wrote:
> :* Dave Voutila <d...@sisu.io> [2018-02-22 23:40:21 -0500]:
> :
> :> > Synopsis:        VMD consumes 100% cpu after unpausing guest
> :> > Category:        amd64
> :> > Environment:
> :>    System      : OpenBSD 6.2
> :>    Details     : OpenBSD 6.2-current (GENERIC.MP) #10: Wed Feb 21 21:26:27 
> MST 2018
> :>                     
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> :> 
> :>    Architecture: OpenBSD.amd64
> :>    Machine     : amd64
> :> 
> :> > Description:
> :> 
> :>        Not sure if this is a known issue, but I couldn't find anything
> :> searching the lists.
> :> 
> :> Using an Alpine Linux guest vm, I can successfully pause the guest using
> :> `vmctl pause 1` and some time later resume it using `vmctl unpause 1`.
> :> 
> :> Unpausing works as the guest comes back to life, I can SSH back in, and
> :> it's fine. However, on the host the vmd process representing that guest
> :> sits at 100% CPU utilization with 1 thread constantly queueing onto a
> :> cpu and running. The guest reports normal load so it must be one of the
> :> 2 threads.
> :
> :This should fix it.
> :
> :Use rtc_reschedule_per in mc146818_start instead of re arming the
> :periodic interrupt without checking if it's enabled in REGB.
> :
> :ok?
> :
> :--
> :Pratik
> :
> :Index: usr.sbin/vmd/mc146818.c
> :===================================================================
> :RCS file: /home/pdvyas/cvs/src/usr.sbin/vmd/mc146818.c,v
> :retrieving revision 1.15
> :diff -u -p -a -u -r1.15 mc146818.c
> :--- usr.sbin/vmd/mc146818.c  9 Jul 2017 00:51:40 -0000       1.15
> :+++ usr.sbin/vmd/mc146818.c  27 Feb 2018 02:47:18 -0000
> :@@ -354,6 +354,6 @@ mc146818_stop()
> :void
> :mc146818_start()
> :{
> :-    evtimer_add(&rtc.per, &rtc.per_tv);
> :     evtimer_add(&rtc.sec, &rtc.sec_tv);
> :+    rtc_reschedule_per();
> :}
> :
>
> This helps a lot with the CPU load on a vmd host.  Drops my single guest
> from ~50% CPU to ~9% CPU on the host.

I can confirm this patch resolves the issue I reported. I _think_ I'm
seeing a similar CPU load drop as well, but definitely have
paused/unpaused the guest multiple times without issues.


Reply via email to