<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">echo 400000 > /sys/module/kvm/parameters/halt_poll_ns</blockquote><div><br></div><div>Tried this change by itself first. CPU was noticeably lower on all cores, almost never exceeding 70%</div><div>The stuttering effect however was much worse.</div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">Next, you have a quad-core+threads processor and you're creating a<br></span><span style="font-size:12.8px">quad-core+threads VM; where's the hypervisor supposed to run?  Of<br></span><span style="font-size:12.8px">course you're going to get stutters when the guest vCPU is preempted by<br></span><span style="font-size:12.8px">the hypervisor or another system process.  Be less aggressive in<br></span><span style="font-size:12.8px">allocating vCPUs, virtualization isn't free.  Try a 3-core+threads VM<br></span><span style="font-size:12.8px">for example.</span></blockquote><div><br></div>Tried 3 cores vs 4 as suggested: "-smp 6,sockets=1,cores=3,threads=2" </div><div> </div><div>Guest consistently locks up during boot. No idea what is up with that :/<br><br>Went all the way down to 2 cores next: "-smp 4,sockets=1,cores=2,threads=2" <br><br>3.11% slower than native now by 3Dmark test, but all my static/jitter issues are totally gone!<br><br>Will have to continue with the other tuning you suggested to find a sweet spot in-between the two extremes, but now I know I am only dealing with CPU starving and not something more complex. Thanks.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 8, 2016 at 9:34 PM, Alex Williamson <span dir="ltr"><<a href="mailto:alex.williamson@redhat.com" target="_blank">alex.williamson@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, 8 May 2016 19:22:43 -0700<br>
"Lance R. Vick" <<a href="mailto:lance@lrvick.net">lance@lrvick.net</a>> wrote:<br>
<br>
> I have some persistent issues with a couple USB devices via vfio/qemu that<br>
> I do not experience when booted native:<br>
><br>
> Oculus Rift CV1<br>
> - head-tracking stutter (any game or demo)<br>
> - host CPU ~100% on every core (any game or demo)<br>
>   - at same time Guest CPU may only show ~20% usage<br>
> - audio static from built-in USB DAC<br>
><br>
> FiiO K1 USB Headphone DAC/AMP<br>
> - mild but noticeable cuts/jitter<br>
><br>
> This may also impact other USB devices in ways I have not yet noticed. Any<br>
> kind of test to quantify this would be helpful. Guest OS was installed on a<br>
> dedicated disk so I can easily native boot to compare tests when needed.<br>
><br>
> 3DMark score is only 0.64% lower in VM which indicates to me at least<br>
> things are -mostly- there:<br>
> <a href="http://www.3dmark.com/compare/fs/8402818/fs/8403766" rel="noreferrer" target="_blank">http://www.3dmark.com/compare/fs/8402818/fs/8403766</a><br>
><br>
> Guest OS is Windows 10 Professional.<br>
><br>
> Any advice/debugging tips would be most welcome.<br>
><br>
> Here are all the other relevant details I can think of for my setup:<br>
<br>
</span>For starters, turn down the kvm module parameter halt_poll_ns to<br>
something like 400000 to see if that brings the host CPU usage down.<br>
<br>
echo 400000 > /sys/module/kvm/parameters/halt_poll_ns<br>
<br>
Kernel v4.4.8 already includes a change to make this the default.<br>
<br>
Next, you have a quad-core+threads processor and you're creating a<br>
quad-core+threads VM; where's the hypervisor supposed to run?  Of<br>
course you're going to get stutters when the guest vCPU is preempted by<br>
the hypervisor or another system process.  Be less aggressive in<br>
allocating vCPUs, virtualization isn't free.  Try a 3-core+threads VM<br>
for example.<br>
<br>
Pinning vCPUs can also reduce stutter, it helps to avoid cold caches<br>
and avoids resource conflicts that can occur with threads.  Switch to<br>
libvirt, it makes this easy.<br>
<br>
Pinning the emulator can help to make sure it doesn't run on a<br>
conflicting CPU to a vCPU.  Libvirt makes this easy to manage.<br>
<br>
Tune irqbalanced to avoid placing interrupts on CPUs used by vCPUs.<br>
<br>
Finally, if you're willing to dedicate CPUs completely to the VM, use<br>
the isolcpus= and nohz_full= boot options to avoid the scheduler<br>
running anything on the physical CPUs except for the vCPUs.<br>
<span class="">><br>
> > sudo qemu-system-x86_64 \<br>
> -enable-kvm \<br>
> -machine type=q35,accel=kvm \<br>
> -cpu host,kvm=off \<br>
<br>
</span>Enable hyper-v extensions, but specify the hv_vendor_id option to avoid<br>
Code43 issues.  Some workloads can have huge benefits from this, things<br>
like 3dmark are mostly unaffected.<br>
<span class=""><br>
> -smp 8,sockets=1,cores=4,threads=2 \<br>
> -m 8G \<br>
> -mem-path /dev/hugepages \<br>
> -device virtio-scsi-pci,id=scsi \<br>
> -drive file=/dev/sda,id=disk,format=raw,if=none \<br>
> -device scsi-hd,drive=disk \<br>
> -device vfio-pci,host=01:00.0,multifunction=on,x-vga=on \<br>
<br>
</span>x-vga=on isn't needed when you're booting the VM with OVMF.<br>
multifunction=on doesn't do anything useful unless you also specify and<br>
addr= option for the devices.<br>
<div class="HOEnZb"><div class="h5"><br>
> -device vfio-pci,host=01:00.1 \<br>
> -drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd<br>
> \<br>
> -drive if=pflash,format=raw,file=/tmp/OVMF_VARS-pure-efi.fd \<br>
> -nographic \<br>
> -vga none \<br>
> -usb \<br>
> -device vfio-pci,host=00:14.0 \<br>
> -rtc clock=host,base=utc<br>
><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Lance R. Vick<br></div>
</div></div>