[vfio-users] CPU pinning with cgroups

[Will Marler]

USB pass-through works quite well with libvirt/virt-manager now; I've used
it for mouse, keyboard, two different audio devices, while the guest was
running. There's one feature request that I haven't gotten around to
submitting; have an "enable/disable" checkbox in the virt-manager gui (I
will not always want to p-t a USB device, but I will want to frequently
enough that deleting it & re-adding it each time gets on my nerves).

On Tue, Sep 8, 2015 at 12:15 AM, Quentin Deldycke <quentindeldycke at gmail.com
> wrote:

> My main problem with libvirt was:
>
>
>    - no ovmf support at the time i created my vm on debian
>    - No correct usb passthrough
>
>
> The qemu monitor support the device_add command. Which let me bind /
> unbind usb devices at runtime, without limit of number.
>
> I really love libvirt at my job, but for this particular case, i found it
> less interesting..
>
>
> --
> Deldycke Quentin
>
>
> On 8 September 2015 at 06:23, Will Marler <will at wmarler.com> wrote:
>
>> Not to mention, you can still see the actual qemu invocation script in
>> the logs when you use libvirt, in case you *really* want to (though a
>> pastebin share of your libvirt xml config is better, imo ...)
>>
>> On Mon, Sep 7, 2015 at 10:15 PM, Jon Panozzo <jonp at lime-technology.com>
>> wrote:
>>
>>> Just to second Alex's point here, I see a lot of folks doing QEMU the
>>> old fashioned way, which is to say, manual invocation.  Libvirt really is
>>> an amazing management solution and makes things so much easier.  Lots of
>>> things can go awry if you're invoking QEMU manually, and libvirt can
>>> prevent that, as well as automate many other aspects of management that
>>> manual QEMU invocation cannot.
>>> On Sep 7, 2015 3:20 PM, "Alex Williamson" <alex.l.williamson at gmail.com>
>>> wrote:
>>>
>>>> On Sun, Sep 6, 2015 at 7:19 PM, Garrett Powell <
>>>> garretttracypowell at gmail.com> wrote:
>>>>
>>>>> I've been having trouble with my guest freezing up, which I'm told is
>>>>> due to a lack of CPU pinning. I'm currently trying to set up CPU pinning
>>>>> with cgroups (specifically cpuset), but the freezing isn't going away.
>>>>> Could anyone tell me what I'm doing wrong? I'm specifically referring to
>>>>> the *cgcreate*, *cgset *and* cgexec* lines. 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 {0..3}; do
>>>>>     echo performance >
>>>>> /sys/devices/system/cpu/cpu${i}/cpufreq/scaling_governor
>>>>> done
>>>>>
>>>>> echo 5120 > /proc/sys/vm/nr_hugepages
>>>>>
>>>>> cgcreate -g cpuset:kvm
>>>>> cgset -r cpuset.cpus=0-3 -r cpuset.mems=0 -r cpuset.cpu_exclusive=1 kvm
>>>>> cgexec -g cpuset:kvm qemu-system-x86_64 \
>>>>>
>>>>
>>>> Ok, so you've change to pCPUs 0-3 instead of 4-7, but doesn't this have
>>>> the same problem as your previous attempt with taskset?  You're using a
>>>> different tool, but afaict you're still not doing 1:1 pinning of vCPUs,
>>>> you're pining them to a set of pCPUs.  Taskset can work, but you need to
>>>> get the thread ID for each vCPU thread and pin it.  The problem is not the
>>>> tool you're using but how you're using it, to set the entire process and
>>>> all the threads it will launch to a range of CPUs rather than pulling out
>>>> the vCPU threads and individually pinning them.  There's this really great
>>>> tool that already does this, it's called libvirt.  Thanks,
>>>>
>>>> Alex
>>>>
>>>> _______________________________________________
>>>> 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/20150908/02eeaa8b/attachment.htm>