First, performance is the only reason that a paravirtualized
version of Xen exists. If Xen did not perform better than
commercial alternatives, I doubt that Xen would be as popular.
One of the first things that many users do when
they try Xen is run benchmarks.
The HV is fairly stable now, at least for domain0. It is
hard to find anything that breaks domain0. DomainU may
cause things to break, but that is because domU has not
been working more than a few days at a time except on
very old trees and it has not been exercised very much.
So I agree that stability and function are higher priority
than performance. That is why I have some of the newer
fast paths turned off; they haven't been adequately tested
with multiple domains. But I think performance is
higher priority than "community members may have other idea
which they want to take a try". So if a real bug is found
that demonstratably impacts stability and function and
that bug fix is incompatible with a fast path (e.g. some
change in fundamental assumptions will require the fast path
to be completely rewritten, not just a change to 2-3 lines),
the fast path should be turned off -- temporarily. But the
fast paths are a critical part of paravirtualized Xen; in
a real world customer setting the vast majority of time spent
in the HV will be in these routines. So it might be wise
for all developers to have some familiarity with how they
work -- and to be able to change one or two lines if necessary.
> For example, vhpt performance is very good under current
> Mangle algorithm, if I want to try some other Mangle
> algorithm, I must modify ten more place (where use Mangle
> algorithm in assembly) in FAST** path.
Is this a rhetorical example? The point of trying other
mangling algorithms is to improve performance. It seems
counter-productive to turn off fast paths to try out something
that is intended to improve performance.
Also, where are the ten places to change? (I only see one.)
Dan
> -----Original Message-----
> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
> Sent: Thursday, December 01, 2005 4:58 AM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] [PATCH] fully virtualize psr
> and ipsr on non-VTIdomain
>
> Dan,
> My patch is intended to make functions like vcpu_get_psr,
> vcpu_set_psr_l, vcpu_ssm, vcpu_rsm, reflection_interrupt
> correct and clear, and it will not add extra overhead.
>
> In your email "Next phase of Xen/ia64 development... ",
> Performance tuning is last item. Stability and function
> implementation have higher priority, I totally agree. As for
> FAST_RFI, FAST_BREAK, FAST_ACCESS_REFLECT, corresponding C
> functions are rewritten in assembly code, and are run in
> guest context, yes it improve performance remarkably, these
> FAST** path doesn't need save/restore guest state and switch
> between bank0 and bank1, I can understand. But I think these
> should be parts of performance tuning and these should be
> done after HV have implemented necessary components and have
> been considerably stable.
> Currently HV is not stable enough, is changed frequently and
> community members may have other idea which they want to take
> a try, if every time when they want to do some modification
> or try new method or algorithm, they must make sure all the
> FAST** work well, which is a huge burden to developer.
> For example, vhpt performance is very good under current
> Mangle algorithm, if I want to try some other Mangle
> algorithm, I must modify ten more place (where use Mangle
> algorithm in assembly) in FAST** path.
> So, IMO we can turn off all FAST** path temporarily, which
> will make our work easy. Because FAST** path are turned off
> temporarily, performance degradation are also temporary. At
> current stage, we should put correctness and flexibility in
> the highest position.
>
>
> Thanks
> -Anthony
>
>
> >-----Original Message-----
> >From: Magenheimer, Dan (HP Labs Fort Collins)
> [mailto:dan.magenheimer@xxxxxx]
> >Sent: 2005年11月30日 21:50
> >To: Xu, Anthony
> >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >Subject: RE: [Xen-ia64-devel] [PATCH] fully virtualize psr
> and ipsr on
> >non-VTIdomain
> >
> >I'm still catching up after being gone for a few days and
> >spent most of yesterday recovering from a trashed disk
> >on my test machine. My first priority is to find out
> >what broke Xen/ia64 in xen-unstable so we have a solid
> >foundation, then I will catch up on the patch backlog.
> >
> >In the meantime, please look at what your patch broke in
> >FAST_RFI, FAST_BREAK, and FAST_ACCESS_REFLECT, as I won't
> >be checking in patches with significant performance
> >regressions.
> >
> >Thanks,
> >Dan
> >
> >> -----Original Message-----
> >> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
> >> Sent: Wednesday, November 30, 2005 2:36 AM
> >> To: Xu, Anthony; Magenheimer, Dan (HP Labs Fort Collins)
> >> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >> Subject: RE: [Xen-ia64-devel] [PATCH] fully virtualize psr
> >> and ipsr on non-VTIdomain
> >>
> >> Dan,
> >>
> >> What's your opinion about this patch?
> >>
> >> Thanks
> >> -Anthony
> >>
> >> >-----Original Message-----
> >> >From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >> >[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On
> >> Behalf Of Xu, Anthony
> >> >Sent: 2005年11月28日 11:22
> >> >To: Magenheimer, Dan (HP Labs Fort Collins)
> >> >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >> >Subject: [Xen-ia64-devel] [PATCH] fully virtualize psr and ipsr on
> >> >non-VTIdomain
> >> >
> >> >Dan,
> >> >This patch is intended to fully virtualize psr and ipsr on non-VTI
> >> >domain.
> >> >Following things are done in this patch.
> >> >1, previously when guest reads psr, it always get psr dt rt
> >> it equal to
> >> >1. that is because HV doesn't restore these information,
> >> >metaphysical_mode can't present all these information. I
> save these
> >> >information into privregs->vpsr. Thus guest can get correct
> >> information
> >> >about dt, rt and it.
> >> >2, when guest reads psr, we should only return low 32bits
> >> and 35 and 36
> >> >bits, previously return all bits.
> >> >3, when guest rsm and ssm psr, HV rsm and ssm some bits of
> >> current psr
> >> >which is used by HV, that is not correct, guest rsm and ssm
> >> should only
> >> >impact guest psr(that is regs->ipsr).
> >> >4, mistakenly uses guest DCR, guest DCR should impact
> guest psr when
> >> >injecting interruption into guest, but not impact guest ipsr.
> >> >When injecting interruption into guest,The current
> implementation is
> >> > Guest ipsr.be=guest dcr.be
> >> > Guest ipsr.pp=guest dcr.pp
> >> >Correct implementation should be,
> >> > Guest psr.be=guest dcr.be
> >> > Guest psr.pp=guest dcr.pp.
> >> >
> >> >Because of above modifications, I turn off FAST_RFI,
> FAST_BREAK and
> >> >FAST_ACCESS_REFLECT.
> >> >
> >> >Signed-off-by Anthony Xu < anthony.xu@xxxxxxxxx>
> >> >
> >> >One question, why do we need to virtualize guest psr.pp and
> >> always set
> >> >guest psr.pp to 1?
> >> >
> >> >Thanks
> >> >-Anthony
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home