[libvirt] Overhead for a default cpu cg placement scheme

Daniel P. Berrange berrange at redhat.com
Thu Jun 11 11:09:36 UTC 2015


On Thu, Jun 11, 2015 at 01:50:24PM +0300, Andrey Korolyov wrote:
> Hi Daniel,
> 
> would it possible to adopt an optional tunable for a virCgroup
> mechanism which targets to a disablement of a nested (per-thread)
> cgroup creation? Those are bringing visible overhead for many-threaded
> guest workloads, almost 5% in non-congested host CPU state, primarily
> because the host scheduler should make a much more decisions with
> those cgroups than without them. We also experienced a lot of host
> lockups with currently exploited cgroup placement and disabled nested
> behavior a couple of years ago. Though the current patch is simply
> carves out the mentioned behavior, leaving only top-level per-machine
> cgroups, it can serve for an upstream after some adaptation, that`s
> why I`m asking about a chance of its acceptance. This message is a
> kind of 'request of a feature', it either can be accepted/dropped from
> our side or someone may give a hand and redo it from scratch. The
> detailed benchmarks are related to a host 3.10.y, if anyone is
> interested in the numbers for latest stable, I can update those.

When you say nested cgroup creation, as you referring to the modern
libvirt hierarchy, or the legacy hierarchy - as described here:

  http://libvirt.org/cgroups.html

The current libvirt setup used for a year or so now is much shallower
than previously, to the extent that we'd consider performance problems
with it to be the job of the kernel to fix.

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 :|




More information about the libvir-list mailing list