qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-ppc] 答复: [qemu-ppc] quesstion ab out kvm e500 tlb search method


From: Wangkai (Kevin,C)
Subject: [Qemu-ppc] 答复: [qemu-ppc] quesstion ab out kvm e500 tlb search method
Date: Thu, 24 Jan 2013 20:02:44 +0000

> Hi Alex,
> 
> In reply your mail:
> Could you please point me to the respective part of the documentation?
> Oh, I am sorry I just see the figure 12-4 of the L2mmu lookup (PowerPC e500 
> Core Family Reference Manual .pdf page 12-8)
> 
> And I check it again, it says:
> Additionally, Figure 12-4 shows that when the L2 MMU is checked for a TLB 
> entry, both TLB1
> and TLB0 are checked in parallel.

>Ah :). Good.

> Let me try to understand what you're trying to fix. Are you seeing 
> performance issues? What kernel are you running on? Are you using hugetlbfs? 
> There are a lot of things that improve performance a lot more than this 
> change would.
> 
> Yes, I used a very old version, which is linux 2.6.34, and I find the 
> performance is not good enough,
> which have no support hugetlbfs, And the code of l2mmu lookup is just walk 
> through all the entry of TLB, and later we will
> Try to merge the new fetcher to this version.

>There have been a number of performance improvements since 2.6.34. Could you 
>please try to run the current upstream code with hugetlbfs on your hardware to 
>get a feeling for what performance numbers are realistic with kvm on e500? 
>With 

>this, you could then either

 > 1) try to backport the current state to 2.6.34 or
 > 2) go to a newer kernel

>but at least you know what is possible with the technology at hand. Running 
>the state as of 2.6.34 any performance numbers will be devastating.

>Also, I have a patch set that is not yet applied upstream, which should speed 
>up TLB1 misses a lot. Please check out

 > http://www.mail-archive.com/address@hidden/msg84609.html

>That one gives you a significant performance boost when running without 
>hugetlbfs - which would be the case on 2.6.34. So if you were to decide for 
>1), you could take the current code plus that patch set and hopefully get 
>reasonable 

>performance out of the system.


>Alex

Ok, thank you for your suggestion, at present, we can only decide 1), and I 
will try the patch, or maybe I can backpoint hugetlb first, and find the
Performance numbers. In the future maybe we can goto the new kernel. 

wangkai


reply via email to

[Prev in Thread] Current Thread [Next in Thread]