On Thu, Jul 02, 2015 at 04:02:58PM +0200, Henning Schild wrote:
Hi,
i am currently looking into realtime VMs using libvirt. My first
starting point was reserving a couple of cores using isolcpus and later
tuning the affinity to place my vcpus on the reserved pcpus.
My first observation was that libvirt ignores isolcpus. Affinity masks
of new qemus will default to all cpus and will not be inherited from
libvirtd. A comment in the code suggests that this is done on purpose.
Ignore realtime + isolcpus for a minute. It is not unreasonable for
the system admin to decide system services should be restricted to
run on a certain subset of CPUs. If we let VMs inherit the CPU
pinning on libvirtd, we'd be accidentally confining VMs to a subset
of CPUs too. With new cgroups layout, libvirtd lives in a separate
cgroups tree /system.slice, while VMs live in /machine.slice. So
for both these reasons, when starting VMs, we explicitly ignore
any affinity libvirtd has and set VMs mask to allow any CPU.
After that i changed the code to use only the available cpus by
default. But taskset was still showing all 'f's on my qemus. Then i
traced my change down to sched_setaffinity assuming that some other
mechanism might have reverted my hack, but it is still in place.
From the libvirt POV, we can't tell whether the admin set isolcpus
because they want to reserve those CPUs only for VMs, or because
they want to stop VMs using those CPUs by default. As such libvirt
does not try to interpret isolcpus at all, it leaves it upto a
higher level app to decide on this policy.
In the case of OpenStack, the /etc/nova/nova.conf allows a config
setting 'vcpu_pin_set' to say what set of CPUs VMs should be allowed
to run on, and nova will then update the libvirt XML when starting
each guest.
Libvirt is setting up cgroups and now my suspicion is that cgroups
and
taskset might not work well together.
> /sys/fs/cgroup/cpu/machine.slice/machine-qemu\x2dvm1.scope/vcpu0#
> cpuacct.usage_percpu
> 247340587 50851635 89631114 23383025 412639264 1241965 55442753 19923
> 14093629 15863859 27403280 1292195745 82031088 53690508 135826421
> 124915000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Looks like the last 16 cores are not used.
But if i use taskset to ask for the affinity mask i get all 32 cpus.
> taskset -p `cat tasks`
> pid 12905's current affinity mask: ffffffff
I know that is not strictly libvirt but also a kernel question, still
you guys are probably able to point me to what i am missing here.
> Linux 3.18.11+ #4 SMP PREEMPT RT
BTW, I dropped Osier from the CC list, since he no longer works
as Red Hat.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|