[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