qemu_set_fd_handler callback is delayed

qemu_set_fd_handler callback is delayed

[Eltahawy, Mahmoud]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

Hi,

I am new to QEMU and I am using qemu-3.0.1, I noticed a strange behavior for qemu_set_fd_handler that the callback for reading from a file descriptor is delayed then expected while the file descriptor(socket) has a data to read.

I register a callback for reading from a socket using qemu_set_fd_handler and during runtime, this callback is not invoked for about 14msec, however the socket has a data available for read. I tested this behavior by just creating a pthread which periodically checks the socket for any data using ioctl(socket_fd, FIONREAD, &count), and for a period of 14ms, I found that the pthread indicates there is a data in the socket while the qemu_set_fd_handler didn't trigger the read callback.

Any advice?


Thanks
Mahmoud



[-- Attachment #2: Type: text/html, Size: 2904 bytes --]

Re: qemu_set_fd_handler callback is delayed

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

On Mon, Dec 30, 2019 at 06:21:27PM +0000, Eltahawy, Mahmoud wrote:
> I am new to QEMU and I am using qemu-3.0.1, I noticed a strange behavior for qemu_set_fd_handler that the callback for reading from a file descriptor is delayed then expected while the file descriptor(socket) has a data to read.
> 
> I register a callback for reading from a socket using qemu_set_fd_handler and during runtime, this callback is not invoked for about 14msec, however the socket has a data available for read. I tested this behavior by just creating a pthread which periodically checks the socket for any data using ioctl(socket_fd, FIONREAD, &count), and for a period of 14ms, I found that the pthread indicates there is a data in the socket while the qemu_set_fd_handler didn't trigger the read callback.

QEMU uses an event loop.  If another handler takes 14 ms to execute,
then the fd handler could be delayed.  Is there other event loop
activity?

Also, a polling thread will respond more quickly than the event loop
because the event loop thread is waiting for the host kernel scheduler
to wake it up.  When the host is under heavy load this could take some
time, depending on the scheduler and its settings.  Was the machine
under heavy CPU load?

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]