From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXKME-0001x0-Gi for qemu-devel@nongnu.org; Wed, 02 Sep 2015 22:34:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXKMB-0008LX-Ab for qemu-devel@nongnu.org; Wed, 02 Sep 2015 22:34:34 -0400 Date: Thu, 3 Sep 2015 12:34:47 +1000 From: David Gibson Message-ID: <20150903023447.GH6537@voom.redhat.com> References: <1440387111-23689-1-git-send-email-bharata@linux.vnet.ibm.com> <20150902032854.GA31862@in.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RwGu8mu1E+uYXPWP" Content-Disposition: inline In-Reply-To: <20150902032854.GA31862@in.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH v0] spapr: Disable memory hotplug when HTAB size is insufficient List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: Nathan Fontenot , khandual@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com --RwGu8mu1E+uYXPWP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 02, 2015 at 08:58:54AM +0530, Bharata B Rao wrote: > On Mon, Aug 24, 2015 at 09:01:51AM +0530, Bharata B Rao wrote: > > The hash table size allocated to guest depends on the maxmem size. > > If the host isn't able to allocate the required hash table size but > > instead allocates less than the optimal requested size, then it will > > not be possible to grow the RAM until maxmem via memory hotplug. > > Attempts to hotplug memory till maxmem could fail and this failure > > isn't being currently handled gracefully by the guest kernel thereby > > causing guest kernel oops. > >=20 > > This should eventually get fixed when we move to completely in-kernel > > memory hotplug instead of the current method where userspace tool drmgr > > drives the hotplug. Until the in-kernel memory hotplug is available > > for PowerKVM, disable memory hotplug when requested hash table size > > isn't allocated. >=20 > David - Do you have any views on how to go about this ? Due to the way > we do hotplug currently using drmgr, it appears that it is very difficult > to have a graceful recovery within the guest kernel when memory hotplug > request can't be fulfilled due to insufficient HTAB size. (Anshuman can > elaborate on this with the exact description on why it is so hard to > recover). >=20 > Do you think disabling memory hotplug upfront is a reasonable workaround > for this problem ? >=20 > Nathan - When you enable in-kernel memory hotplug for PowerKVM, will you > be exporting something for the userspace (capability ?) to check and > determine the presense of in-kernel memory hotplug feature so that we > can depend on graceful recovery instead of upfront disablement of > memory hotplug from QEMU ? So, I kind of dislike magically disabling requested options - it can make debugging problems really confusing. In theory, what I'd prefer is to just not start the guest if we don't get a big enough hash table to cover maxram. Unfortunately we don't discover this until reset time at which point it is not straightforward to bail out cleanly :/ --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --RwGu8mu1E+uYXPWP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV57HGAAoJEGw4ysog2bOSVzQQAN9mEvInWvYbHwyjuUn2Fr4L y5rH9ea/7nTjPeLUTCssfuQrd9fM5X1jFbycEthTfBKZWbN4POtygn2PfhH7kP4i Bq1GXQeXzpAG0IdoZKM/GZNjEvqsUP58F1kwfF+dnS0+T0oCHaHNmwEhSw3yxjaw Oxs657oYon3bgoUgPsJyjZwtMkMUKdnxQ7gIn4OE0ugU1qrsiMs3DnUSrsGEZhcy sNdXfb8jdYyLBvwF/rP6uuXMCbg1VQRaZ6cyjxb2qd2XbF4B18IX08mQ8ovh+pZi l/7RlntHDYO5HBd5Y/yUYMIYb1FiuTM5BVpIyRXC7OCj4VTF5V3I/T1Uk8CaAdy0 apjiidRTA52kHHQFvrfAsLBc2WHTVfvI0duSn3BMeVY/dxtK2iB4fsdKoAHAESHE +Rk5mxkvrDth5hNd4i8pccAwx3R3kT028LGN2D5E+HVT1NKsddGNgn6vMtsLI7q3 U9uXB/AGgLiZYT61TKW1zThNXy40itB75/i8BUpH5QBhsEcNJI+rsuyyQI8NcLfs kvl5Y1vrJdtchbEjGU586MZaCE+0nKbIRxRXkLRCLxq0K2MHyxmDP7WAAS/AMiA+ cheluATqEPczH6iMW6sNjMUBe16xVLtl/l+v6BKKwe116+xtIgQNec21QqJcfRMK K5YdMXoprk9FlJlZo/YX =5LPy -----END PGP SIGNATURE----- --RwGu8mu1E+uYXPWP--