[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xen-ia64-devel] [PATCH] Enable hash vtlb
- To: "Xu, Anthony" <anthony.xu@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
- From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
- Date: Fri, 7 Apr 2006 09:42:32 -0700
- Delivery-date: Fri, 07 Apr 2006 09:42:58 -0700
- List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
- Thread-index: AcZaOCQZxD2/LTjiSWCJJGOwhZ+0cwAKHVcg
- Thread-topic: [Xen-ia64-devel] [PATCH] Enable hash vtlb
> The kernel build time is about 2040s without this patch.
> The kernel build time is about 2085s with this patch.
> Means this patch loses 2% performance.
Um, 2% may not seem like a big deal (big cake?) when measuring
VTI performance, but it approximately doubles the overhead for
I thought the whole point of this patch was to improve
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. Tying these changes together
in a single patchset is not a good idea.
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, I don't think
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. We should revisit it
after Isaku's VP patches are integrated and stable as
getting VP/vnif/ballooning working is higher priority.
Just my two cents...
Xen-ia64-devel mailing list