lkml.org 
[lkml]   [2011]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v1 00/19] Increase resolution of load weights
On Thu, May 12, 2011 at 2:08 AM, Peter Zijlstra <peterz@infradead.org> 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
http://berrange.com/posts/2009/12/03/using-cgroups-with-libvirt-and-lxckvm-guests-in-fedora-12/

$ROOT
|
+- 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 ;-)
-Thanks,
Nikhil


\
 
 \ /
  Last update: 2011-05-12 19:33    [from the cache]
©2003-2011 Jasper Spaans