[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: single software TLB vs. multiple software TLBs (was RE: [Xen-ia64-devel] [PATCH] [Resend]Enable hash vtlb)
- To: <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
- From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
- Date: Thu, 13 Apr 2006 20:20:14 +0800
- Delivery-date: Thu, 13 Apr 2006 05:20:32 -0700
- List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
- Thread-index: AcZeQwzGkG/7QGfmRJiAmulTDR9D4QAr6vLg
- Thread-topic: single software TLB vs. multiple software TLBs (was RE: [Xen-ia64-devel] [PATCH] [Resend]Enable hash vtlb)
It becomes much clear now that multiple softsware TLB support is a must in
functionality. For at least following reasons:
1: We should merge VTI and para domain vMMU code together to reduce
future maintaince effort. In this case multiple software TLB support for MMIOs
is a must for VTI domain and thus a must for Xen/IA64.
2: Para domain needs to capture guest MMIO access too in case a native
driver in guest detect its existance. Definitely we should not crash system in
that case, so multiple software TLB support is a must too.
3: Multiple software TLBs provides flexibility for guest huge TLB
Anthony's patch is ready to support all of above as a functionality
ready solution, and so far I didn't see anybody against multiple software TLB
support. Can u check in now as a build option? The performance difference in
1-2 percent should be a second level consideration for now.
Thanks very much!
Tristan Gingold wrote:
> Le Mercredi 12 Avril 2006 16:51, Dong, Eddie a écrit :
>> Tristan Gingold wrote:
>> At every tlb miss time, you can get guest translation from software
>> TLB (not from VHPT). You actually don't need to care about VHPT
>> entries no matter it is all there or nothing there.
> Ok, it is clear now.
Xen-ia64-devel mailing list