[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xen-ia64-devel] [PATCH] [Resend]Enable hash vtlb
- To: "Xu, Anthony" <anthony.xu@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
- From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
- Date: Sat, 8 Apr 2006 08:49:27 +0800
- Delivery-date: Fri, 07 Apr 2006 17:49:42 -0700
- List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
- Thread-index: AcZadd1hYhceJ/vUTve3HHZ7F0IKNwALuXGg
- Thread-topic: [Xen-ia64-devel] [PATCH] [Resend]Enable hash vtlb
Alex, Dan & all:
I believe this patch should be in shortly. The reason is that:
1: We don't want to have different memory management approach
between VTI & non-VTI domain. Otherwise every effort like smp.g need to
be double implemented in both VTI and non-VTI. People will soon ask each
patch changing memory management code need to be proven on VTI domain
2: While #1 must have multiple software TLBs for MMIO at least.
Current para-domain approach has only single software TLB that must be
extent to support multiple software TLBs.
3: I think nobody will against hash data structure for those
software TLBs in #2, thus hash vTLB is a must patch from correctness
point of view.
Further more, hash vTLB gain some performance for us base on
People can still argu how should VHPT be implemented, like
GLOBAL, per LP, per VP etc. But we this debate should not block hash
vTLB patch, it is kind of 2 different thing we are mixing. And the
community has decided to implement this feature at xensummit and are
waiting for this for long time ....
Xu, Anthony wrote:
> Hash vTLB is intended to address SMP scalability for large system.
> Kernel build on dom0 loses about 2% performance,
> While dom0 can support non-contiguous memory, and can address
> Hugetlb issue. Those incur performance degradation.
> Kernel build on domU gains about 1% performance.
> Signed-off-by: Anthony Xu <anthony.xu@xxxxxxxxx>
Xen-ia64-devel mailing list