Re: [Qemu-devel] [RFC PATCH v0] spapr: Disable memory hotplug when HTAB size is insufficient

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2290 bytes --]

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.
> > 
> > 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.
> 
> 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).
> 
> Do you think disabling memory hotplug upfront is a reasonable workaround
> for this problem ?
> 
> 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 :/

-- 
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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]