linux-kernel - Re: [PATCH v1 00/19] Increase resolution of load weights

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]

Message-ID: <BANLkTimsvvWqcGanJs688hytLx1_jb0itw@mail.gmail.com>
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/