qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [4341] qemu: generate signals on tap I/O


From: Anthony Liguori
Subject: Re: [Qemu-devel] [4341] qemu: generate signals on tap I/O
Date: Mon, 05 May 2008 17:43:45 -0500
User-agent: Thunderbird 2.0.0.12 (X11/20080227)

Aurelien Jarno wrote:
Revision: 4341
          http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=4341
Author:   aurel32
Date:     2008-05-05 21:26:43 +0000 (Mon, 05 May 2008)

Log Message:
-----------
qemu: generate signals on tap I/O

Currently tap does not generate signals on I/O; this causes
network latency to be dependent on the timer tick (1ms without
dyntick, guest dependent with dyntick).  By generating a signal
on I/O, we can inform the guest immediately that a packet has
arrived.

Signed-off-by: Aurelien Jarno <address@hidden>

Modified Paths:
--------------
    trunk/vl.c

Modified: trunk/vl.c
===================================================================
--- trunk/vl.c  2008-05-05 21:26:31 UTC (rev 4340)
+++ trunk/vl.c  2008-05-05 21:26:43 UTC (rev 4341)
@@ -4030,6 +4030,7 @@
     if (!s)
         return NULL;
     s->fd = fd;
+    enable_sigio_timer(fd);
     s->vc = qemu_new_vlan_client(vlan, tap_receive, NULL, s);
     qemu_set_fd_handler(s->fd, tap_send, NULL, s);
     snprintf(s->vc->info_str, sizeof(s->vc->info_str), "tap: fd=%d", fd);

I still haven't seen anyone explain why this results in a performance improvement. The SIGIO handler is tied to the host_alarm_handler which will not dispatch IO. It surprises me that it has any affect at all.

FWIW, we're getting rid of SIGIO in KVM. It doesn't improve performance verses a properly implemented select lop.

Regards,

Anthony Liguori








reply via email to

[Prev in Thread] Current Thread [Next in Thread]