Re: [Xen-devel] xen-unstable qemu-upstream: pci-passthrough timing issues due to commit 0f7b2864d0d0c3ef2801f9214d8c510c80a220d1 when vnc enabled

[Gerd Hoffmann <kraxel@xxxxxxxxxx>]

On 04/22/13 12:10, Sander Eikelenboom wrote:
> 
> Monday, April 22, 2013, 12:01:02 PM, you wrote:
> 
>> Are you sure that the bug is related to Xen PCI passthrough (it
>> doesn't happen if you don't assign any devices to the Xen guest)? I
>> am asking because the Xen PCI passthrough code doesn't use any
>> timers, while this looks like something related to timer and
>> refresh intervals...

> Ok latency issue would perhaps be a better description. I think
> something in this change make it worse, hence resulting in the driver
> of the passthroughed pci device reporting that it's buffer was empty
> (4 times) and then the buffer is filled up with 4 frames where it
> expected only 1.

irq latencies probably.  Although ... is qemu involved in the irq
delivery path in the first place?

How frequent are these latency spikes?

> Anyhow i noticed that running with "nographic" dramatically reduces
> the overhead of the qemu process in dom0 compared to running with
> graphics. Which seems strange since it's a console only linux guest
> and no vnc clients are connected ...

The gui update rate is adaptive and ranges from .03 seconds minimum to 3
seconds maximum.  With an active guest you'll see the refresh interval
close to the lowest limit.  With an idle guest (doing no screen updates)
the update rate goes down step by step until it reaches 3 seconds after
a while.

Enable the "console_refresh" tracepoint and you should see the logic at
work.

With no vnc client connected it should always stay at the maximum (3
seconds).  An vnc screen update every three seconds should not cause a
dramatic change, especially as there is next to nothing to do when the
guest doesn't update the screen.

cheers,
  Gerd

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel