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

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


  • To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.