Re: [libvirt] Suboptimal default cpu Cgroup

2014-08-15 14:44+0100, Daniel P. Berrange: > On Fri, Aug 15, 2014 at 09:23:35AM -0400, Andrew Theurer wrote: > > > On Thu, Aug 14, 2014 at 01:55:11PM -0400, Andrew Theurer wrote: > > > > > From: "Radim Krčmář" <rkrcmar(a)redhat.com&gt; > > > > > 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. > > If we hadn't already had this behaviour in libvirt for 3+ years then sure > it would be desirable to change it. At this point though, applications > have been exposed to current semantics for a long time and can have setup > usage policies which are relying on this. If we change the defaults we have > a non-negligible risk of causing regressions in behaviour for our existing > userbase. I think that (enterprise) distributions are for this preservation and upstream is only looking forward, so we don't end in the huge pile that is created throughout years.