[lkml]   [2011]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v1 00/19] Increase resolution of load weights
    On Thu, May 12, 2011 at 2:08 AM, Peter Zijlstra <> wrote:
    > On Thu, 2011-05-05 at 18:29 -0700, Nikhil Rao wrote:
    >> > It's a cost/benefit analysis and for 32-bit systems the benefits seem to be
    >> > rather small, right?
    >> >
    >> Yes, that's right. The benefits for 32-bit systems do seem to be limited.
    > deep(er) hierarchies on 32 bits still require this, it would be good to
    > verify that the cgroup mess created by the insanity called libvirt will
    > indeed work as expected.

    I went through the libvirt docs and from what I understand, it creates
    a hierarchy which is about 3 levels deep and has as many leaf nodes as
    guest VMs.

    Taking this graphic from

    +- libvirt (all virtual machines/containers run by libvirtd)
    +- lxc (all LXC containers run by libvirtd)
    | |
    | +- guest1 (LXC container called 'guest1')
    | +- guest2 (LXC container called 'guest2')
    | +- guest3 (LXC container called 'guest3')
    | +- ... (LXC container called ...)
    +- qemu (all QEMU/KVM containers run by libvirtd)
    +- guest1 (QENU machine called 'guest1')
    +- guest2 (QEMU machine called 'guest2')
    +- guest3 (QEMU machine called 'guest3')
    +- ... (QEMU machine called ...)

    Assuming the tg shares given to libvirt, lxc and qemu containers are
    the defaults, the load balancer should be able to deal with the
    current resolution on 32-bit. Back of the envelope calculations using
    that approach I mentioned earlier (i.e. log_b(1024/NR_CPU)) says you
    need > 64 VMs before you run out of resolution. I think that might be
    too much to expect from a 8-cpu 32-bit machine ;-)


     \ /
      Last update: 2011-05-12 19:33    [W:0.023 / U:2.944 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site