[vfio-users] Anything more I can do to improve CPU performance?

[Garrett Powell]

Thanks Alex, this helps a lot. I'll remove *taskset *from the launch script
and use *cpuset* instead. After reading through the man page for *cpuset*,
I think it looks doable via the command line, but I want some clarification
on something: One of the parameters for *cpuset* (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 *-smp* parameter in the launch script to? Let me know if
I'm misunderstanding something.

-Garrett

On Sun, Sep 6, 2015 at 2:52 PM Alex Williamson <alex.l.williamson at gmail.com>
wrote:

> On Sun, Sep 6, 2015 at 12:39 PM, Garrett Powell <
> garretttracypowell at gmail.com> wrote:
>
>> 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.
>>
>> Here's my launch script:
>>
>> #!/bin/bash
>>
>> export QEMU_AUDIO_DRV=pa
>> export QEMU_PA_SERVER=localhost
>> export PULSE_SERVER=localhost
>>
>> vfio-bind 0000:06:00.0
>>
>> synergys --daemon --config /etc/synergy.conf
>>
>> for i in {4..7}; do
>>     echo performance >
>> /sys/devices/system/cpu/cpu${i}/cpufreq/scaling_governor
>> done
>>
>> echo 5120 > /proc/sys/vm/nr_hugepages
>>
>> taskset -ac 4-7 qemu-system-x86_64 \
>>
> ...
>
>> Is there anything more I can do? Am I doing anything wrong?
>>
>
> 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.
>
> 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,
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20150906/a954064e/attachment.htm>