In bug 1247075 we introduced a new cpu_affinity option to pin vdsm threads to a limited number of physical cores to solve a GIL contention on thread scheduling Testing didn't show any adverse effects, only benefits (improvement is proportional to the size of the host and number of VMs it's running) Let's enable it by default
using 'taskset 0' pins Vdsm to the first CPU, which is usually a bit more busy than others. Using 'taskset 1' assume that the host has at least two CPUs. That's true in every real-life scenario. Gil, is it also correct on all QE setups, where virtual hosts are sometime used?
Please note that http://gerrit.ovirt.org/48619 should take care of this uncommon -but important- cases.
now really MODIFIED, all patches merged on branch 3.6
Please set target release or I can't move the bug to ON_QA automatically.
Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.
Should move this to next build.
patch reverted in build 23 onwards, solution moved to 3.6.2
# rpm -qi vdsm Name : vdsm Version : 4.17.18 Release : 0.el7ev Architecture: noarch Install Date: Wed 20 Jan 2016 06:30:30 PM UTC Group : Applications/System Size : 3802272 License : GPLv2+ Signature : RSA/SHA256, Wed 20 Jan 2016 05:31:13 PM UTC, Key ID 938a80caf21541eb Source RPM : vdsm-4.17.18-0.el7ev.src.rpm Build Date : Tue 19 Jan 2016 12:34:08 PM UTC Build Host : x86-017.build.eng.bos.redhat.com Relocations : (not relocatable) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Vendor : Red Hat, Inc. URL : http://www.ovirt.org/wiki/Vdsm Summary : Virtual Desktop Server Manager # grep affinity /var/log/vdsm/vdsm.log MainThread::INFO::2016-01-27 09:47:12,758::vdsm::282::vds::(__set_cpu_affinity) VDSM will run with cpu affinity: frozenset([1])