> On Thu, Aug 14, 2014 at 01:55:11PM -0400, Andrew Theurer wrote: > > > > > > ----- Original Message ----- > > > From: "Radim Krčmář" <rkrcmar@xxxxxxxxxx> > > > To: libvir-list@xxxxxxxxxx > > > Cc: "Daniel P. Berrange" <berrange@xxxxxxxxxx>, "Andrew Theurer" > > > <atheurer@xxxxxxxxxx> > > > Sent: Thursday, August 14, 2014 9:25:05 AM > > > Subject: Suboptimal default cpu Cgroup > > > > > > Hello, > > > > > > by default, libvirt with KVM creates a Cgroup hierarchy in 'cpu,cpuacct' > > > [1], with 'shares' set to 1024 on every level. This raises two points: > > > > > > 1) Every VM is given an equal amount of CPU time. [2] > > > ($CG/machine.slice/*/shares = 1024) > > > > > > Which means that smaller / less loaded guests are given an advantage. > > > > > > 2) All VMs combined are given 1024 shares. [3] > > > ($CG/machine.slice/shares) > > > > > > This is made even worse on RHEL7, by sched_autogroup_enabled = 0, so > > > every other process in the system is given the same amount of CPU as > > > all VMs combined. > > > > > > It does not seem to be possible to tune shares and get a good general > > > behavior, so the best solution I can see is to disable the cpu cgroup > > > and let users do it when needed. (Keeping all tasks in $CG/tasks.) > > > > Could we have each VM's shares be nr_vcpu * 1024, and the share for > > $CG/machine.slice be sum of all VM's share? > > Realistically libvirt can't change what it does by default for VMs wrt > to this cgroups setting, because it would cause an immediate functional > change for any who has deployed current libvirt versions & upgrades. Is this another way of saying, "we have already set a bad precedent, so we need to keep it"? I am concerned that anyone who may be experiencing this problem may be unsure of what is causing it, and is not aware of how to fix it. > Management apps like oVirt or OpenStack should explicitly set the policy > they desire in this respect. Shouldn't a user or upper level mgmt have some expectation of sane defaults? A user or mgmt app has already specified a preference in the number of vcpus -shouldn't that be enough? Why have this fix need to be pushed to multiple upper layers when it can be remedied in just one (libvirt)? Honestly, I don't understand how this even got out the way it is. -Andrew > > 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 :| > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list