On Tue, 2010-06-22 at 15:20 +0300, Avi Kivity wrote: > On 06/22/2010 03:14 PM, Alexander Graf wrote: > > Avi Kivity wrote: > > > >> On 06/22/2010 03:10 PM, Alexander Graf wrote: > >> > >>> If you have more performance hints, I'll gladly take them :). > >>> > >>> > >> Using a cpu that virtualizes the mmu in hardware helps tremendously. > >> > >> > > PPC never does that. Even with the virtualization extensions the MMU is > > still software managed. > > 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 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. 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 was also more thinking of hints like > > "kmem_cache_zalloc is slow" or so ;). > > > > Stuff like that is usually worthless. To give real feedback I need to > understand the hardware, so I'm reduced to coding style and indentation > review. In that case, I'd say that BAT manipulation is rare enough (mostly only at boot time) to warrant indeed speeding up the normal PTE operations & invalidations at the expense of the BAT change case. 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
