On 10.09.2010, at 01:39, Hollis Blanchard wrote: > On 09/09/2010 04:26 PM, Alexander Graf wrote: >> On 09.09.2010, at 20:13, Hollis Blanchard wrote: >> >>> On 09/09/2010 04:16 AM, Liu Yu-B13201 wrote: >>> >>>> Yes, it's hard to resume TLB0. We only resume TLB1 in previous code. >>>> But TLB1 is even more smaller (13 free entries) than 440, >>>> So that it still has little possibility to get hit. >>>> thus the resumption is useless. >>>> >>>> >>> The only reason hits are unlikely in TLB1 is because you still don't have >>> large page support in the host. Once you have that, you can use TLB1 for >>> large guest mappings, and it will become extremely likely that you get hits >>> in TLB1. This is true even if the guest wants 256MB but the host supports >>> only e.g. 16MB large pages, and must split the guest mapping into multiple >>> large host pages. >>> >>> When will you have hugetlbfs for e500? That's going to make such a dramatic >>> difference, I'm not sure it's worth investing time in optimizing the MMU >>> code until then. >>> >> I'm not sure I agree. Sure, huge pages give another big win, but the state >> as is should at least be fast enough for prototyping. >> > Sure, and it sounds like you can prototype with it already. My point is that, > in your 80-20 rule of optimization, the 20% is going to change radically once > large page support is in place. > > Remember that the guest kernel is mapped with just a couple large pages. > During guest Linux boot on 440, I think about half the boot time is spent TLB > thrashing in the initcalls. Using TLB0 can ameliorate that for now, but why > bother, since it doesn't help you towards the real solution? > > I'm not saying this shouldn't be committed, if that's how you interpreted my > comments, but in my opinion there are more useful things to do than > continuing to optimize a path that is going to disappear in the future. Once > you *do* have hugetlbfs in the host, you're not going to want to use TLB0 for > guest TLB1 mappings any more anyways.
That depends on the use cases. As long as there are no transparent huge pages available, not using hugetlbfs gives you a lot of benefit: - ksm - swapping - lazy allocation So while I agree that supporting huge pages is crucial to high performance kvm, I'm not convinced it's the only path to optimize for. Look at x86 - few people actually use hugetlbfs there. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
