Re: [RFC 0/3] Prototype PAPR hash page table resizing (guest side)

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

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

On Mon, Dec 28, 2015 at 10:09:52AM +0530, Anshuman Khandual wrote:
> On 12/24/2015 04:08 PM, David Gibson wrote:
> > On Thu, Dec 24, 2015 at 02:52:53PM +0530, Anshuman Khandual wrote:
> >> > On 12/22/2015 10:44 AM, David Gibson wrote:
> >>> > > I've discussed with Paul and Ben previously the possibility of
> >>> > > extending PAPR to allow changing the size of a running guest's hash
> >>> > > page table (HPT).  This would allow for much more flexible memory
> >>> > > hotplug, since the HPT wouldn't have to be sized in advance for the
> >>> > > maximum possible memory size of the guest.
> >> > 
> >> > Does it include reducing the size of HPT as well ?
> > It does, but that could fail with H_PTEG_FULL if there's a collision
> > between bolted entries in the reduced table.
> 
> So in the case when we request for a reduced size HPT table, as mentioned
> in the second implementation method, will we allocate the required smaller
> HPT table to shadow the original or we just reduce the original HPT in
> size without allocating a new one ?

The current implementation will allocate a new HPT and free the
original one once the transition is complete.  It might be possible to
avoid that and reduce the HPT in place, but doing a rollback in case
of collision will be a lot hairier.

-- 
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: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]