From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <aliguori@us.ibm.com>
Subject: [PATCH] Throttle consoled to work-around xcs
Date: Thu, 04 Aug 2005 16:14:02 -0500
Message-ID: <42F2851A.1000406@us.ibm.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="------------060907040606000304030002"
Return-path: <xen-devel-bounces@lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: xen-devel <xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

This is a multi-part message in MIME format.
--------------060907040606000304030002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

Regards,

Anthony Liguori

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com

--------------060907040606000304030002
Content-Type: text/x-patch;
 name="consoled_throttling.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="consoled_throttling.diff"

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);
+		}
 		enum_domains();
 
 		if (FD_ISSET(xcs_data_fd, &readfds)) {

--------------060907040606000304030002
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------060907040606000304030002--