From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkzOQ-0007jp-UE for qemu-devel@nongnu.org; Thu, 15 May 2014 13:24:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkzNw-00033S-3r for qemu-devel@nongnu.org; Thu, 15 May 2014 13:24:30 -0400 Received: from mail1.windriver.com ([147.11.146.13]:35963) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkzNv-00032y-Rm for qemu-devel@nongnu.org; Thu, 15 May 2014 13:24:00 -0400 Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail1.windriver.com (8.14.5/8.14.5) with ESMTP id s4FHNtgg005166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 15 May 2014 10:23:58 -0700 (PDT) Message-ID: <5374F82A.7050205@windriver.com> Date: Thu, 15 May 2014 11:23:54 -0600 From: Chris Friesen MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] [bug] busy-loop in send_all() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, I've run into a situation that seems like a bug. I'm using qemu 1.4.2 (with additional patches) from within openstack. I'm using virtio-serial-pci to provide a channel between the guest and host. On occasion when doing suspend/resume I run into a case where the main qemu thread ends up chewing 100% of a cpu. I attached strace to the thread and it showed qemu just spitting messages: write(35, "HRBT\0\1\0\3d<\230k\0\0\0\0\0\0\1\330\0\0\0\0enqueue\0"..., 472) = -1 EAGAIN (Resource temporarily unavailable) write(35, "HRBT\0\1\0\3d<\230k\0\0\0\0\0\0\1\330\0\0\0\0enqueue\0"..., 472) = -1 EAGAIN (Resource temporarily unavailable) write(35, "HRBT\0\1\0\3d<\230k\0\0\0\0\0\0\1\330\0\0\0\0enqueue\0"..., 472) = -1 EAGAIN (Resource temporarily unavailable) write(35, "HRBT\0\1\0\3d<\230k\0\0\0\0\0\0\1\330\0\0\0\0enqueue\0"..., 472) = -1 EAGAIN (Resource temporarily unavailable) File descriptor 35 is the unix socket corresponding to the virtio-serial port. I broke in with gdb and got a backtrace showing it was in send_all(). Looking at the implementation of send_all(), the core loop looks like: while (len > 0) { ret = write(fd, buf, len); if (ret < 0) { if (errno != EINTR && errno != EAGAIN) return -1; } else if (ret == 0) { break; } else { buf += ret; len -= ret; } } So if we get EAGAIN, we'll just immediately retry. I'm not sure where the unix socket would get opened, but I'm assuming it's set as non-blocking? And by default /proc/sys/net/unix/max_dgram_qlen is set to 10. So if the other end of that unix socket is connected but isn't actually paying attention to the messages then the first 10 messages will get buffered but after that we'll end up with qemu spinning forever in a busy-loop trying to send a message into a full buffer. This seems less than ideal. Either we should block, or else we should discard the data. And I don't think discarding the data makes sense. Chris