From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46913) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8WFv-0005mF-21 for qemu-devel@nongnu.org; Thu, 02 Jun 2016 13:18:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8WFs-0003kT-87 for qemu-devel@nongnu.org; Thu, 02 Jun 2016 13:18:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48712) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8WFs-0003kJ-2Y for qemu-devel@nongnu.org; Thu, 02 Jun 2016 13:18:00 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B953E8EFEB for ; Thu, 2 Jun 2016 17:17:57 +0000 (UTC) Received: from [10.36.7.27] (vpn1-7-27.ams2.redhat.com [10.36.7.27]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u52HHtKs003085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Jun 2016 13:17:57 -0400 References: <201606010952.u519n6ri025307@mx0a-001b2d01.pphosted.com> <574EB66E.1040805@redhat.com> <20160602004222.GE15455@voom.fritz.box> <201606020440.u524ZiVe027809@mx0a-001b2d01.pphosted.com> <574FDA33.3040001@redhat.com> <20160602140737.GB18628@in.ibm.com> From: Thomas Huth Message-ID: <57506A43.1010900@redhat.com> Date: Thu, 2 Jun 2016 19:17:55 +0200 MIME-Version: 1.0 In-Reply-To: <20160602140737.GB18628@in.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v0 0/2] Increase max memslots to 512 for PowerPC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 02.06.2016 16:07, Bharata B Rao wrote: > On Thu, Jun 02, 2016 at 09:03:15AM +0200, Thomas Huth wrote: >> On 02.06.2016 06:39, Bharata B Rao wrote: >> ... >>> Agreed. Here is the updated patch: >>> >>> spapr: Increase hotpluggable memory slots to 256 >>> >>> From: Bharata B Rao >>> >>> KVM now supports 512 memslots on PowerPC (earlier it was 32). Allow half >>> of it (256) to be used as hotpluggable memory slots. >>> >>> Instead of hard coding the max value, use the KVM supplied value if KVM >>> is enabled. Otherwise resort to the default value of 32. >>> >>> Signed-off-by: Bharata B Rao >>> --- >>> hw/ppc/spapr.c | 15 +++++++++++++-- >>> 1 file changed, 13 insertions(+), 2 deletions(-) >>> >>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c >>> index 44e401a..c82adef 100644 >>> --- a/hw/ppc/spapr.c >>> +++ b/hw/ppc/spapr.c >>> @@ -1816,11 +1816,22 @@ static void ppc_spapr_init(MachineState *machine) >>> /* initialize hotplug memory address space */ >>> if (machine->ram_size < machine->maxram_size) { >>> ram_addr_t hotplug_mem_size = machine->maxram_size - machine->ram_size; >>> + /* >>> + * Number of memslots supported by KVM on PowerPC was increased >>> + * from 32 to 512. Let us limit the number of hotpluggable slots >>> + * to half of that (256). However ensure that number of slots >>> + * doesn't drop below 32 on older hosts. >>> + */ >> >> Using "hard-coded" information like "increased to 512" in comments is >> true for the current state, but this has a risk of being out of date >> soon. Once we change the memslots in the kernel, this comment is not >> true anymore and might cause confusion. Better talk about leaving half >> of the kernel memslots for PCI and other devices, or so. > > Just want to note that even though we are limiting hotpluggable memory > slots to half of max, it is always possible for other devices to eat > into the memory hotplug slots, right ? Right. But 256 slots for those other devices is already plenty, I think. Let's hope that it is enough for a while - if it's not enough, we've got to rework the kernel code again (and maybe switch to dynamic memslots allocation instead). Thomas