qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [qemu-ppc] quesstion about kvm e500 tlb search method


From: Alexander Graf
Subject: Re: [Qemu-ppc] [qemu-ppc] quesstion about kvm e500 tlb search method
Date: Thu, 24 Jan 2013 15:50:49 +0100

On 24.01.2013, at 15:36, Wangkai (Kevin,C) wrote:

> 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




reply via email to

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