Re: [PATCH 1/2] KVM: PPC: Add generic hpte management functions

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Sun, 2010-06-27 at 10:53 +0300, Avi Kivity wrote:
> On 06/27/2010 01:58 AM, Benjamin Herrenschmidt wrote:
> >
> >> Then mmu intensive loads can expect to be slow.
> >>      
> > Well, depends. ppc64 indeed requires the hash to be managed by the
> > hypervisor, so inserting or invalidating translations will mean a
> > roundtrip to the hypervisor, though there are ways at least the
> > insertion could be alleviated (for example, the HV could service the
> > hash misses directly walking the guest page tables).
> >    
> 
> But the guest page tables are software defined, no?  That means the 
> interface will break if the page table format changes.

Yes. Unless the hypervisor or architecture defines the format to be
used :-) IE. That's what Niagara 1 did. But we don't do that indeed
currently.

> > But that's due in part to a design choice (whether it's a good one or
> > not I'm not going to argue here) which favors huge reasonably static
> > workloads where the hash is expected to contain all translations for
> > everything.
> >    
> 
> What about when you have memory pressure?  The hash will have to reflect 
> those pte_clear_flush_young(), no?

Well, our architects would argue that the kind of workloads we target
don't have memory pressure :-)

But yes, I agree, harvesting of dirty and young bits is going to force a
hash flush which can be pretty expensive. Heh, we've been trying to
convince our own architects at designers that the MMU sucks for long
enough...

> It seems horribly expensive.
> 
> > However, note that BookE (the embedded variant of the architecture) uses
> > a different model for virtualization, including options in its latest
> > variant for a HW logical->real translation (via a small dedicated TLB)
> > and direct access to some TLB ops from the guest.
> >    
> 
> I'm somewhat familiar with it, yes.

Cheers,
Ben.