WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

RE: [Xen-ia64-devel] [PATCH] Enable hash vtlb

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] [PATCH] Enable hash vtlb
From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
Date: Sat, 8 Apr 2006 01:29:34 +0800
Delivery-date: Fri, 07 Apr 2006 10:30:11 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZaOCQZxD2/LTjiSWCJJGOwhZ+0cwAKHVcgAADC1cA=
Thread-topic: [Xen-ia64-devel] [PATCH] Enable hash vtlb
Hi Dan,
Thanks for your comments

>From: Magenheimer, Dan 
>Sent: 2006?4?8? 0:43
>Um, 2% may not seem like a big deal (big cake?) when measuring
>VTI performance, but it approximately doubles the overhead for
>non-VTI.
>
Sorry for not clear, 2% degradation is measured on dom0.
Major of 2% suffer from supporting non-contiguous memory on dom0,
This is a must for supporting VP, and device domain.

>I thought the whole point of this patch was to improve
>performance?
I don't think so, VTLB is introduced to satisfy scalability,
Which is decided on Xen Summit, if I'm not poor remember.

>
>I agree with Tristan that if there are multiple purposes
>for this patch, they should be broken out and submitted
>individually.  For example, if your TLB mapping fix solves
>the "gcc segmentation fault" issue, even if there is a
>performance hit, the fix should be accepted.  However,
>adding collision chains should only be done if it is
>shown to improve performance.
Collision chains can be configurable, currently nobody know
the impact to performance, we need to get the answer on 
performance tune stage.

> Tying these changes together
>in a single patchset is not a good idea.
>
Accept,

>And if the patchset (or a subset of it) *doesn't* fix the
>"gcc segmentation fault" issue AND causes a performance
>degradation AND only fixes a theoretical bug,

This is not a theoretical bug; hugetlb is extensively used on linux
server, this bug doesn't show up only because currently there is 
no hugetlb on para-linux, hugetlb must be supported. This is a REAL
bug, para-dom doesn't fully emulate "itc".

>it should be applied now as it changes enough fundamental
>hypervisor code that it is reasonable to expect that it
>may introduce other subtle bugs.

Yes, I should split this patch, staff related with hypervisor
code has nothing to do with VTLB, this is a bug fix.

As we know, now there is no good solution for hypervisor to pass
parameter through pointer. For example, get_pfn_list hypercall
cause hypervisor use copy_to_user function to copy pfn_list to
guest space. If there is a tlb miss happening and can't be handled by
hypervisor, this hypercall will fail, and this domain will be destroyed.

Maybe this is a good time to discuss how to pass parameter thr pointer.

>  We should revisit it
>after Isaku's VP patches are integrated and stable as
>getting VP/vnif/ballooning working is higher priority.
>
These are two different threads.


>Just my two cents...
>Dan

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel