[vfio-users] CPU pinning with cgroups

Tue Sep 8 17:11:04 UTC 2015

I don’t think that’s true if you use the startupPolicy option of “optional”.  From libvirt domain XML documentation:

Since 1.0.0, the source element of USB devices may contain startupPolicy attribute which can be used to define policy what to do if the specified host USB device is not found. The attribute accepts the following values:

mandatory	fail if missing for any reason (the default)
requisite		fail if missing on boot up, drop if missing on migrate/restore/revert
optional		drop if missing at any start attempt

> On Sep 8, 2015, at 9:56 AM, Blank Field <ihatethisfield at gmail.com> wrote:
> 
> ...but wait, there's more!
> If you unplug the p-t'd device from the host while VM is offline, the VM will fail to boot.
> There's still a lot of work to be done with USB.
> 
> On Sep 8, 2015 5:51 PM, "Will Marler" <will at wmarler.com <mailto:will at wmarler.com>> wrote:
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto:alex.l.williamson at gmail.com>> wrote:
> On Sun, Sep 6, 2015 at 7:19 PM, Garrett Powell <garretttracypowell at gmail.com <mailto: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 <mailto:vfio-users at redhat.com>
> https://www.redhat.com/mailman/listinfo/vfio-users <https://www.redhat.com/mailman/listinfo/vfio-users>
> 
> 
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com <mailto:vfio-users at redhat.com>
> https://www.redhat.com/mailman/listinfo/vfio-users <https://www.redhat.com/mailman/listinfo/vfio-users>
> 
> 
> 
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com <mailto:vfio-users at redhat.com>
> https://www.redhat.com/mailman/listinfo/vfio-users <https://www.redhat.com/mailman/listinfo/vfio-users>
> 
> 
> 
> 
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com <mailto:vfio-users at redhat.com>
> https://www.redhat.com/mailman/listinfo/vfio-users <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/216b421a/attachment.htm>