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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
