>> A VF interrupt usually happens in 4-8KHZ. How about the virtio?
>> I assume virtio will be widely used together w/ leagcy guest with
>> INTx mode.
>>
>
> True, but in time it will be replaced by MSI.
>
> Note without vhost virtio is also in userspace, so there are lots of
> exits anyway for
On 06/10/2010 05:37 AM, Dong, Eddie wrote:
Avi Kivity wrote:
On 06/09/2010 06:59 PM, Dong, Eddie wrote:
Besides VF IO interrupt and timer interrupt introduced performance
overhead risk,
VF usually uses MSI
Typo, I mean PV IO.
That also uses MSI these days.
A VF
Avi Kivity wrote:
> On 06/09/2010 06:59 PM, Dong, Eddie wrote:
>>
>> Besides VF IO interrupt and timer interrupt introduced performance
>> overhead risk,
>
> VF usually uses MSI
Typo, I mean PV IO.
A VF interrupt usually happens in 4-8KHZ. How about the virtio?
I assume virtio will be widely u
Avi Kivity wrote:
> I am currently investigating a problem with the a guest running Linux
> malfunctioning in the NMI watchdog code. The problem is that we don't
> handle NMI delivery mode for the local APIC LINT0 pin; instead we
> expect ExtInt deliver mode or that the line is disabled completely
On 06/09/2010 06:59 PM, Dong, Eddie wrote:
Besides VF IO interrupt and timer interrupt introduced performance overhead
risk,
VF usually uses MSI
EOI message deliver from lapic to ioapic,
Only for non-MSI
which becomes in user land now, may have potential scalability issue. For
exam
On 06/08/2010 01:23 AM, Anthony Liguori wrote:
A better example would be a generic counter kernel mechanism. I can
envision such a device as doing nothing more than providing a
read-only view of a counter with a userspace configurable divider
and width. Any write to the counter or read of any
On 06/07/2010 01:42 PM, Avi Kivity wrote:
On 06/07/2010 08:04 PM, Anthony Liguori wrote:
I think we could also move the local APIC.
I'm not even sure we can safely move the ioapic/pic (mostly due to
churn). But the local APIC is so heavily accessed by the guest that
it's impossible to move
On 06/07/2010 09:54 PM, David S. Ahern wrote:
So it's important to know how often your RHEL3/4 guest queries the PIT
(not just receives interrupts, actually reads the counter) under a
realistic load. If you have such a number (in reads/sec) that would be
a good input to this discussion.
On 06/07/10 12:46, Avi Kivity wrote:
> On 06/07/2010 07:31 PM, David S. Ahern wrote:
>>
>> On 06/07/10 09:26, Avi Kivity wrote:
>>
>>
>>> The original motivation for moving the PIC and IOAPIC into the kernel
>>> was performance, especially for assigned devices. Both devices are high
>>> inter
On 06/07/2010 07:31 PM, David S. Ahern wrote:
On 06/07/10 09:26, Avi Kivity wrote:
The original motivation for moving the PIC and IOAPIC into the kernel
was performance, especially for assigned devices. Both devices are high
interaction since they deal with interrupts; practically after e
On 06/07/2010 08:04 PM, Anthony Liguori wrote:
I think we could also move the local APIC.
I'm not even sure we can safely move the ioapic/pic (mostly due to
churn). But the local APIC is so heavily accessed by the guest that
it's impossible to move it. Run an ftrace one day, especially on
On 06/07/2010 10:26 AM, Avi Kivity wrote:
I am currently investigating a problem with the a guest running Linux
malfunctioning in the NMI watchdog code. The problem is that we don't
handle NMI delivery mode for the local APIC LINT0 pin; instead we
expect ExtInt deliver mode or that the line is
On 06/07/10 09:26, Avi Kivity wrote:
> The original motivation for moving the PIC and IOAPIC into the kernel
> was performance, especially for assigned devices. Both devices are high
> interaction since they deal with interrupts; practically after every
> interrupt there is either a PIC ioport
13 matches
Mail list logo
