Re: [RFCv3 00/17] PAPR HPT resizing, guest & host side

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

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

On Thu, Aug 25, 2016 at 10:38:34PM +1000, Paul Mackerras wrote:
> On Mon, Mar 21, 2016 at 02:53:07PM +1100, David Gibson wrote:
> > This is an implementation of the kernel parts of the PAPR hashed page
> > table (HPT) resizing extension.
> > 
> > It contains a complete guest-side implementation - or as complete as
> > it can be until we have a final PAPR change.
> > 
> > It also contains a draft host side implementation for KVM HV (the KVM
> > PR and TCG host-side implementations live in qemu).  This works, but
> > is very slow in the critical section (where the guest must be
> > stopped).  It is significantly slower than the TCG/PR implementation;
> > unusably slow for large hash tables (~2.8s for a 1G HPT).
> > 
> > I'm still looking into what's the cause of the slowness, and I'm not
> > sure yet if the current approach can be tweaked to be fast enough, or
> > if it will require a new approach.
> 
> I have finally managed to have a close look at this series.  The
> approach and implementation seem basically sane,

Ok, good to know.

> though I think the
> rehash function could be optimized a bit.  I also have an optimized
> implementation of hpte_page_size() and hpte_base_page_size() which
> should be a lot quicker than the 2d linear (areal?) search which we do
> at present.

Ok, sounds like with those optimizations this approach might be good
enough.  I aim to send a revised version of these some time after the
RHEL 7.3 crunch.

In the meantime, any word on the PAPR proposal?

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