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

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


  • To: "Yang, Fred" <fred.yang@xxxxxxxxx>, "Xu, Anthony" <anthony.xu@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Fri, 7 Apr 2006 11:19:05 -0700
  • Delivery-date: Fri, 07 Apr 2006 11:20:09 -0700
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcZaOCQZxD2/LTjiSWCJJGOwhZ+0cwAKHVcgAADzXaAAApuSMA==
  • Thread-topic: [Xen-ia64-devel] [PATCH] Enable hash vtlb

> >I thought the whole point of this patch was to improve
> >performance?
> 
> As discussed long time before as well as proposed in Xen Summit as an
> option, Hash vTLB is mainly to address SMP scalability for 
> lager system
> like Itanium.  It may still matches current global VHPT performance in
> UP if take out vTLB's key fetaures for SMP.

OK, so it is intended to improve performance on large SMP
systems.  Do we have any measurements on large SMP systems
to show that it did indeed improve performance on a large
SMP system?
 
> >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 sentence sounds like "unless vTLB fixes gcc, it shouldn't be in"
> :-)  Somehow this is a fair call to the real purpose of the hash vTLB.
> vTLB is not meant to fix bug, it is to provide scalability feature,
> period!  
> Please note the GCC issue  is not introduced by vTLB , rather it has
> been there long ago!  Community effort is definitely needed 
> to nail this
> sneaky bug introduced long ago.

No, you missed my point.  I was saying if ANY patch fixes the
gcc segmentation fault, a performance degradation may be acceptable.
I understand fixing that problem is not the point of this patch.

> >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.  
> 
> As the project goes, we should really decide a patch base on if it is
> architecturally needed to support Xen/IPF to achieve its best system
> performance, not base on if it changes fundermental code or not!  If a
> design is needed, a short-term pain in addressing bugs is better than
> long-term unaddressed issues.  

Agreed.  I am discussing tradeoffs of performance vs stability vs
functionality.  On our current aggressive schedule, I would place
networking functionality above stability, but I wouldn't place
hugetlb functionality or huge SMP performance above stability.
Others may disagree.

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®.