<div dir="ltr"><div>Thanks Alex, this helps a lot. I'll remove <i>taskset </i>from the launch script and use <i>cpuset</i> instead. After reading through the man page for <i>cpuset</i>, I think it looks doable via the command line, but I want some clarification on something: One of the parameters for <i>cpuset</i> (cpuset.cpus) specifies "the CPUs that tasks in this cgroup are permitted to access". What exactly does this mean? If I set the value to 0-3, will that allocate four vCPUs across two pCPUs (two each) or four vCPUs across four pCPUs (one each)? Do I want to allocate half of my vCPUs to the host and half to the guest, or could I allocate 2 vCPUs to the host and 6 to the guest? Finally, what would I set the <i>-smp</i> parameter in the launch script to? Let me know if I'm misunderstanding something.<br><br></div>-Garrett<span class="term"></span><br><div><div><div><br><div class="gmail_quote"><div dir="ltr">On Sun, Sep 6, 2015 at 2:52 PM Alex Williamson <<a href="mailto:alex.l.williamson@gmail.com" target="_blank">alex.l.williamson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Sep 6, 2015 at 12:39 PM, Garrett Powell <span dir="ltr"><<a href="mailto:garretttracypowell@gmail.com" target="_blank">garretttracypowell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I've been noticing lately that a particularly CPU intensive game has been keeping my CPU usage at >95%, and the game's been unplayable as a result. With an i7-4820k clocked at 4.7GHz, I should be getting much better performance. I've tried using some of the performance enhancements from the Arch forum thread, including enabling hyper-v enlightenments, but that caused my graphics driver to exit with error 43.<div><br></div><div>Here's my launch script:</div><div><br></div><div><div>#!/bin/bash</div><div><br></div><div>export QEMU_AUDIO_DRV=pa</div><div>export QEMU_PA_SERVER=localhost</div><div>export PULSE_SERVER=localhost</div><div><br></div><div>vfio-bind 0000:06:00.0</div><div><br></div><div>synergys --daemon --config /etc/synergy.conf</div><div><br></div><div>for i in {4..7}; do</div><div> echo performance > /sys/devices/system/cpu/cpu${i}/cpufreq/scaling_governor</div><div>done</div><div><br></div><div>echo 5120 > /proc/sys/vm/nr_hugepages</div><div><br></div><div>taskset -ac 4-7 qemu-system-x86_64 \</div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>... </div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Is there anything more I can do? Am I doing anything wrong?</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Your taskset is probably killing you, that's not the way to pin vCPUs. Effectively what you're doing is pinning all the qemu processes to pCPU 4-7, without pinning anything to any one specific processor. So not only are your vCPUs floating around among those pCPUs, sometimes running on one, sometimes on another, but you're forcing them to share those pCPUs with the emulator itself. Unfortunately doing vCPU pinning correctly via the commandline is a pain in the butt. It's trivially easy via libvirt though. Libvirt also allows pinning the emulator to different cpusets and I offered some interesting experiments using that in a latency post to this list last week.</div><div><br></div><div>Your choice of pCPUs is also poor as you're giving the host one half of each core (thread0) and the VM the other half (thread1). So if the host does anything at all, it's preempting a vCPU. Remember, threads share a core and it's going to be a real miracle if the host scheduler and guest scheduler can coordinate to cooperatively share a core. Thanks,</div><div><br></div><div>Alex</div></div></div></div>
</blockquote></div></div></div></div></div>