This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] [PATCH] Throttle consoled to work-around xcs

To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH] Throttle consoled to work-around xcs
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Thu, 04 Aug 2005 16:14:02 -0500
Delivery-date: Thu, 04 Aug 2005 21:12:42 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
Instead of queuing messages when the control channels are full, xcs just does nothing (see ctrl_interface.c:ctrl_chan_write_request()).

The following patch throttles the rate in which consoled writes data to xcs. With the current values, you get a responsive console but avoid data corruption in most scenarios.

I'm able to get pretty far in my regression test with this patch. With higher throttle values I'm able to get even further (but the console becomes painfully slow).

I implemented proper control channel queuing in xenctld in VM-Tools and it's pretty nasty stuff. This should prevent corruption for most users until we can get rid of xcs.


Anthony Liguori

Signed-off-by: Anthony Liguori <aliguori@xxxxxxxxxx
diff -r 60c4cd9ebaa1 tools/consoled/io.c
--- a/tools/consoled/io.c       Wed Aug  3 16:11:32 2005
+++ b/tools/consoled/io.c       Thu Aug  4 16:03:26 2005
@@ -288,6 +288,7 @@
        fd_set readfds, writefds;
        int ret;
        int max_fd = -1;
+       int num_of_writes = 0;
        do {
                struct domain *d;
@@ -312,6 +313,17 @@
                ret = select(max_fd + 1, &readfds, &writefds, 0, &tv);
+               if (tv.tv_sec == 1 && (++num_of_writes % 100) == 0) {
+                       /* FIXME */
+                       /* This is a nasty hack.  xcs does not handle the
+                          control channels filling up well at all.  We'll
+                          throttle ourselves here since we do proper
+                          queueing to give the domains a shot at pulling out
+                          the data.  Fixing xcs is not worth it as it's
+                          going away */
+                       tv.tv_usec = 1000;
+                       select(0, 0, 0, 0, &tv);
+               }
                if (FD_ISSET(xcs_data_fd, &readfds)) {
Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [PATCH] Throttle consoled to work-around xcs, Anthony Liguori <=