about vEOI optimization

about vEOI optimization

[Tian, Kevin]

Hi, Avi,

Both Eddie and Marcello once suggested vEOI optimization by skipping
heavy-weight instruction decode, which reduces vEOI overhead greatly:

http://www.mail-archive.com/kvm@vger.kernel.org/msg18619.html 
http://www.spinics.net/lists/kvm/msg36691.html

Though virtual x2apic serves similar purpose, it depends on guest OS
to support x2apic. Many Windows versions don't support x2apic though,
including Win7, Windows server before 2008 R2, etc. Given that virtualization
need support various OS versions, any chance to incorporate above vEOI
optimization in KVM as an alternative to boost performance when guest
doesn't support x2apic?

Thanks
Kevin

Re: about vEOI optimization

[Avi Kivity]

On 08/23/2011 11:09 AM, Tian, Kevin wrote:
> Hi, Avi,
>
> Both Eddie and Marcello once suggested vEOI optimization by skipping
> heavy-weight instruction decode, which reduces vEOI overhead greatly:
>
> http://www.mail-archive.com/kvm@vger.kernel.org/msg18619.html
> http://www.spinics.net/lists/kvm/msg36691.html
>
> Though virtual x2apic serves similar purpose, it depends on guest OS
> to support x2apic. Many Windows versions don't support x2apic though,
> including Win7, Windows server before 2008 R2, etc. Given that virtualization
> need support various OS versions, any chance to incorporate above vEOI
> optimization in KVM as an alternative to boost performance when guest
> doesn't support x2apic?
>

Yes.  There was a problem with the guest using MOVSD or STOSD to write 
the EOI; if we don't emulate, then registers don't get updated.  I guess 
we can ignore it since no sane guest will use those instructions for EOI.

Another option is the hyper-V EOI support, which can also eliminate the 
EOI exit when no additional interrupt is pending.  This can improve EOI 
performance even more.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

RE: about vEOI optimization

[Tian, Kevin]

> From: Avi Kivity [mailto:avi@redhat.com]
> Sent: Wednesday, August 24, 2011 6:00 PM
> 
> On 08/23/2011 11:09 AM, Tian, Kevin wrote:
> > Hi, Avi,
> >
> > Both Eddie and Marcello once suggested vEOI optimization by skipping
> > heavy-weight instruction decode, which reduces vEOI overhead greatly:
> >
> > http://www.mail-archive.com/kvm@vger.kernel.org/msg18619.html
> > http://www.spinics.net/lists/kvm/msg36691.html
> >
> > Though virtual x2apic serves similar purpose, it depends on guest OS
> > to support x2apic. Many Windows versions don't support x2apic though,
> > including Win7, Windows server before 2008 R2, etc. Given that virtualization
> > need support various OS versions, any chance to incorporate above vEOI
> > optimization in KVM as an alternative to boost performance when guest
> > doesn't support x2apic?
> >
> 
> Yes.  There was a problem with the guest using MOVSD or STOSD to write
> the EOI; if we don't emulate, then registers don't get updated.  I guess
> we can ignore it since no sane guest will use those instructions for EOI.

yes, sane guests all use MOV for EOI. btw, Xen has integrated a similar
acceleration for several releases. When we're measuring 10G SR-IOV
network performance, vEOI access overhead may be up to 6%-8% based
on interrupt rate which is one factor for KVM to lag behind.

> 
> Another option is the hyper-V EOI support, which can also eliminate the
> EOI exit when no additional interrupt is pending.  This can improve EOI
> performance even more.
> 

yes, and this is an orthogonal option.

So if you agree, I'll send out an updated patch atop their work.

Thanks
Kevin

Re: about vEOI optimization

[Avi Kivity]

On 08/25/2011 05:24 AM, Tian, Kevin wrote:
> >
> >  Another option is the hyper-V EOI support, which can also eliminate the
> >  EOI exit when no additional interrupt is pending.  This can improve EOI
> >  performance even more.
> >
>
> yes, and this is an orthogonal option.
>
> So if you agree, I'll send out an updated patch atop their work.
>
>

Thanks.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.