[PATCH] Throttle consoled to work-around xcs

[Anthony Liguori <aliguori@us.ibm.com>]

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

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

[-- Attachment #2: consoled_throttling.diff --]
[-- Type: text/x-patch, Size: 846 bytes --]

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)) {

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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