public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Dor Laor <dor.laor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [PATCH] KVM: VMX:	Enable	memory	mappedTPR	shadow(FlexPriority)
Date: Wed, 31 Oct 2007 15:08:29 +0200	[thread overview]
Message-ID: <47287E4D.8050102@qumranet.com> (raw)
In-Reply-To: <4727D09E.2040008-atKUWr5tajBWk0Htik3J/w@public.gmane.org>

Avi Kivity wrote:
> Dong, Eddie wrote:
>   
>>> Yes. FlexPriority will be both faster and safer for those who have it
>>> than my hack. 
>>>
>>> It may turn out that patching can improve performance even with
>>> FlexPriority: we can patch the APIC EOI write to look if any
>>> interrupts are pending, and only exit if the EOI will result in a new
>>> interrupt being injected. But it is very possible that this will not
>>> be necessary if we can achieve good interrupt mitigation with virtio.
>>>
>>>     
>>>       
>> Mmm, I won't say so. The issues is: A guest EOI (level triggered IRQ)
>> need to clear remote IRR bit in IOAPIC side and resample that pin in
>> IOAPIC side.
>> This one is not easy to do in patched code.
>>
>>   
>>     
>
> Hmm...
>
> The patched code needs to answer the question "what will happen if I EOI 
> this vector now"?  I think kvm can prepare the answer for that question, 
> since it knows the irq is still asserted and that the mode is 
> level-triggered.
>
> Basically the kvm lapic code has to calculate the IRR for a "speculative 
> EOI" and post that in the shared memory block.  If something changes 
> (the IRQ line is de-asserted, for example) again it has to recalculate it.
>
> So yes, it will not be easy.
>
>   
IMHO high performing devices like virtio have good irq 
coalescing/mitigation so there is no need to
optimize their path. Also even if you we had this improvement there is 
another time that passes
between the time that the irq is acked by the guest and the time that 
higher layer tasklet is scheduled and
really handles the action for that interrupt (duting this time more data 
should reach the host).
Since NAPI/virtio handles these situations also there is no need to have 
optimizations in the middle.
Regards,
Dor

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

  parent reply	other threads:[~2007-10-31 13:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-29  4:55 [PATCH] KVM: VMX: Enable memory mapped TPR shadow(FlexPriority) Yang, Sheng
     [not found] ` <DB3BD37E3533EE46BED2FBA80995557FA15F3E-wq7ZOvIWXbM/UvCtAeCM4rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-10-29 11:35   ` Izik Eidus
     [not found]     ` <1193657732.4484.17.camel-siXIhNkUrCXckEVJwWePHtCfPAL7FxvL@public.gmane.org>
2007-10-30 11:40       ` [PATCH] KVM: VMX: Enable memory mappedTPR shadow(FlexPriority) Dong, Eddie
     [not found]         ` <10EA09EFD8728347A513008B6B0DA77A024CEC5E-wq7ZOvIWXbNpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-10-30 11:46           ` Avi Kivity
     [not found]             ` <472719A1.6070709-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-10-30 15:07               ` Dong, Eddie
     [not found]                 ` <10EA09EFD8728347A513008B6B0DA77A024CECAA-wq7ZOvIWXbNpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-10-31  0:47                   ` Avi Kivity
     [not found]                     ` <4727D09E.2040008-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-10-31 13:08                       ` Dor Laor [this message]
2007-10-31 14:26                       ` Dong, Eddie
2007-10-30  3:25   ` [PATCH] KVM: VMX: Enable memory mapped TPR shadow(FlexPriority) Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47287E4D.8050102@qumranet.com \
    --to=dor.laor-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
    --cc=dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox