Keir Fraser write on 2006年11月22日 15:07:
> On 22/11/06 3:33 am, "Xu, Anthony" <anthony.xu@xxxxxxxxx> wrote:
>
>> After moving from sharing PIC to hypercall set irq.
>> KB on UP VTI domain incurs > 10% degradation.
>>
>> The root cause is hypercall is very expensive on IPF side
>> due to huge processor context.
>>
>> I revert to sharing PIC in lastest Cset of IPF side,
>> Then We can get performance back.
>
> We may well have similar degradation on x86 too. The cause is lots of
> unnecessary calls to the set_level hypercall (when the level hasn't
> actually changed). Qemu *definitely* needs to keep shadow wire state
> and only notify Xen on transitions. If the rate of hypercalls is
> still too high (which I think is unlikely) we can use batching
> multicalls.
I have tried shadow wire state in IPF side, filtered out unnecessary set_level
hypercalls,
But I can only get about 50% performance degradation back.
In IPF side, I set all interrupt edge( there is no sharing interrupt in my
environment), so 1->0, 0->0 and 1->1
is not Passed to xen by hypercall, only 0->1 is passed to xen by hypercall,
then about half of set_level
hypercalls are saved. But this can only get ~50% performance degradation back.
In previous shared PIC method, it is likely that interrupt and IO finish are
passed to xen by only one
hypercall xc_evtchn_notify.
But now we may need to use two hypercalls xc_evtchn_notify and set_level
hypercalls,
I think this is reason of another 50% performance degradation.
Batching multicall may be a good idea,
The only question is how and when we batch xc_evtchn_notify and set_level
hypercall,
When xc_evtchn_notify is called, there may be several set_level hypercall
should be called,
But set_level hypercall is based on irq line level, how to "remember" several
set_level hypercalls?
Maybe we need to change set_level hypercall interface.
>
>> I prepare to use shared IOSAPIC to deliver interrupt from
>> Qemu to VTI domain.
>> In IPF side, PIC is not needed,
>> In the same time, we can assign more interrupt pins(24) to qemu.
>
> I moved x86 away from this on purpose, to obtain a clean abstraction.
> I don't think it's a good idea for ia64 to step backwards here.
Actually I don't want to do this, if there are better solution to pull back
performance.
-- Anthony
>
> -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home