lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 12 May 2011 10:30:56 -0700
From:	Nikhil Rao <ncrao@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Mike Galbraith <efault@....de>,
	linux-kernel@...r.kernel.org,
	"Nikunj A. Dadhania" <nikunj@...ux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Stephan Barwolf <stephan.baerwolf@...ilmenau.de>
Subject: Re: [PATCH v1 00/19] Increase resolution of load weights

On Thu, May 12, 2011 at 2:08 AM, Peter Zijlstra <peterz@...radead.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ