[vfio-users] cpu usage in guest != cpu usage in host, even with exclusive pinning

[Garland Key]

I'm having this same issue but the 100% cpu spike isn't degrading gameplay
somehow, so I don't care for now.  Hoping it will be fixed in next kernel
update.

On Mon, Mar 21, 2016 at 1:13 PM Jon Panozzo <jonp at lime-technology.com>
wrote:

> Can confirm 4.2.8 kernel doesn’t exhibit this behavior with the same QEMU
> package and VM guest.  So taking the exact same software configuration to
> the 4.2.8 kernel results in normal CPU usage, but with any 4.4.x kernel
> variant I’ve tried thus far, I’ve seen the same 100% usage.
>
> It seems to apply when any media application is in use (3D, audio, or
> video).  Just playing an MP3 for me caused the host to go to 100%.  And if
> I leave shadowplay running, it stays at 100% as well.  Any application that
> pulls on a VFIO passed-through device seems to cause this to occur for me.
>
> > On Mar 17, 2016, at 3:55 PM, Jon Panozzo <jonp at lime-technology.com>
> wrote:
> >
> > Also experiencing this with Linux kernel 4.4.5 and QEMU 2.5.0.  Odd
> behavior indeed.
> >
> >> On Feb 14, 2016, at 9:34 PM, globalgorrilla at fastmail.fm wrote:
> >>
> >> Still the same with 4.5-rc4 and AUR qemu-git.
> >>
> >> On 23 Jan 2016, at 18:55, Dan Ziemba wrote:
> >>
> >>> On Tue, 2016-01-19 at 16:52 +0100, Friedrich Oslage wrote:
> >>>> I did some more testing and it turns out to be a kernel error,
> >>>> introduced somewhere around linux 4.3.
> >>>>
> >>>> Short description of the error: 100% cpu usage while using 3d in a vm
> >>>> with vfio
> >>>>
> >>>> My last known good kernel is 4.2.8, which gives me about 20% cpu
> >>>> usage
> >>>> while playing Diablo III. My first known bad kernel is 4.3.3, which
> >>>> gives me 100% cpu usage with every game, even while idle-ling in the
> >>>> menu.
> >>>>
> >>>> On 01/17/2016 10:29 AM, Friedrich Oslage wrote:
> >>>>> my host system is linux-4.4.0 with qemu-2.5.0 and a 4-core i7.
> >>>>> Linux is
> >>>>> booted with isolcpus=1-3,5-7 to reserve 3 cores + threads for the
> >>>>> Windows 10 VM.
> >>>>> The VM's 3 cores(2 threads each) are pinned to the respective
> >>>>> physical
> >>>>> core/thread. The iothread is pinned to 1-3,5-7.
> >>>
> >>> Interesting, I've also noticed similar behavior since upgrading to
> >>> kernel 4.4 and qemu 2.5.0.  I am running 4 cores / 8 threads for the VM
> >>> and pinned to individual host threads by libvirt, but I didn't boot
> >>> with the isolcpus arg. Emulator threads are pinned to the remaining 4
> >>> host threads.
> >>>
> >>> Host is a i7-5930K, so 6 cores.  Guest is running Win 8.1.
> >>>
> >>> Just sitting at the pause screen in Fallout: New Vegas, I have a single
> >>> CPU running at 100% according to both the windows task manager and the
> >>> host.  The host cpu thread that is at 100% is one of the ones with a
> >>> vcpu pinned to it.  In the guest, it does appear that the game is the
> >>> thing using all the CPU cycles, and the GPU is basically idle at this
> >>> time.
> >>>
> >>> When I was previously running kernel 4.1.15 and qemu 2.4, New Vegas was
> >>> never demanding enough to max out any one cpu no matter what I was
> >>> doing with the game.  Same goes for more demanding games such as GTA V.
> >>>
> >>>
> >>> I upgraded both kernel and qemu at the same time, so I can't say which
> >>> caused it.  I haven't really noticed much difference in performance. If
> >>> anything, it might be slightly better.  I seemed to notice less frame
> >>> rate drops and stuttering while playing GTA V after the upgrade.
> >>>
> >>> Dan
> >>>
> >>> _______________________________________________
> >>> vfio-users mailing list
> >>> vfio-users at redhat.com
> >>> https://www.redhat.com/mailman/listinfo/vfio-users
> >>
> >> _______________________________________________
> >> vfio-users mailing list
> >> vfio-users at redhat.com
> >> https://www.redhat.com/mailman/listinfo/vfio-users
> >
>
>
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160322/f8993898/attachment.htm>