From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [patch] qemu-kvm introduce -maxcpus argument Date: Sun, 21 Jun 2009 15:53:05 +0300 Message-ID: <4A3E2D31.6020101@redhat.com> References: <4A3B99DD.50306@gmail.com> <20090619141527.GA18392@redhat.com> <4A3B9F4D.3000907@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Daniel P. Berrange" , Gleb Natapov , "kvm@vger.kernel.org" To: Jes Sorensen Return-path: Received: from mx2.redhat.com ([66.187.237.31]:43100 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750967AbZFUMwW (ORCPT ); Sun, 21 Jun 2009 08:52:22 -0400 In-Reply-To: <4A3B9F4D.3000907@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/19/2009 05:23 PM, Jes Sorensen wrote: > >> libvirt currently does >> >> fd = open("/dev/kvm") >> r = ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_NR_VCPUS); >> >> to figure out what the maximum allowed vCPUs will be for KVM, >> and currently it is returning 16 IIRC. > > Interesting, this will need to be addressed as well. I have plans to > introduce a mechanism telling the kernel where the limit will be, in > order to allow it to allocate data structures in a reasonable manner. I prefer to have the kernel adjust dynamically. The vcpu array wants 8 bytes per vcpu, so for 256 vcpus we're still a very reasonable 2K. For (say) 4K vcpus, we'll need to reallocate the array dynamically, for which rcu will be perfect or better. >> This implies the limit (for x86 pc machine at least) is now 255. Is that >> the correct interpretation on my part ? > > Actually the 255 limit is tied to ACPI. Once we support ACPI 3.0 and > x2apic, it will get much worse. Be afraid, be very afraid :-) To be > honest, that is going to be a while before we get to that, but I hope > to get to it eventually. > > I strongly recommend you try not to impose static limits within libvirt > for the number of vCPUs. > > I guess it will become a tricky issue who is telling who what the limit > is. Ideally I would like to see the kernel limit becoming unlimited and > the restrictions being set by userland. The kernel needs some kind of limit to avoid resource exhaustion. Could be set quite high. Beyond that there should be additional setup. Note for 4K vcpus you'll need to increase the maximum opened files opened by a process, threads, etc. -- error compiling committee.c: too many arguments to function