From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R98mz-0005yz-Ah for qemu-devel@nongnu.org; Thu, 29 Sep 2011 01:04:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R98mx-0008GZ-QC for qemu-devel@nongnu.org; Thu, 29 Sep 2011 01:04:05 -0400 Received: from lemon.ertos.nicta.com.au ([203.143.174.143]:38907 helo=lemon.ken.nicta.com.au) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R98mx-0008FO-Gt for qemu-devel@nongnu.org; Thu, 29 Sep 2011 01:04:03 -0400 Date: Thu, 29 Sep 2011 15:03:53 +1000 Message-ID: From: Peter Chubb In-Reply-To: <4E83F86B.2020208@mail.berlios.de> References: <4E83F86B.2020208@mail.berlios.de> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Qemu-devel] [PATCH] Remove line buffering from log file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: bernard.blackham@nicta.com.au, Peter Chubb , qemu-devel@nongnu.org, philipo@ok-labs.com >>>>> "Stefan" == Stefan Weil writes: Stefan> Am 29.09.2011 04:43, schrieb Peter Chubb: >> >> This patch was originally written by Bernard Blackham, and modified >> by Peter Chubb. >> >> From 0d755af2f5bef22432da71f2fe0a9dce7d2882cd Mon Sep 17 00:00:00 >> 2001 From: Bernard Blackham Date: >> Fri, 24 Jul 2009 13:38:03 +1000 Subject: Disable line-based log >> buffering. >> >> There's no real reason for line-based buffering in log file output. >> If block buffering with a decent sized buffer is used, it can speed >> qemu up for -d all or -d exec significantly. >> >> The only thing you lose is that the last up to 4k of log output may >> be lost if qemu crashes. Stefan> That's the reason why line buffering is needed today. I Stefan> enable log file output to see what happened last before the Stefan> crash. Thanks for this, I didn't think of this use-case. I don't think I've ever seen a qemu crash that wasn't caused by something really obvious. Stefan> It might be possible to use buffered output with a new Stefan> function qemu_abort() which replaces the existing calls of Stefan> abort(). This function could call flush() for the log output Stefan> before aborting. In addition, SIGSEGV needs to be catched, Stefan> and the signal handler would have to call flush(), too (is Stefan> that possible in signal handlers?). abort() already flushes all open streams. So only signals that cause immediate death are a problem: SIGSEGV is the obvious one. If its handler called abort() then that would flush too. abort() is guaranteed by the POSIX spec to be callable from a signal handler. I'll experiment by adding such a handler and see what happens. Do you have a test case that causes a SEGV? Stefan> Speed is not the primary target when somebody runs qemu -d ... It is if it takes hours to reach the problem that causes the abort(). Speeding up by an order of magnitude is worth it. -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au http://www.ertos.nicta.com.au ERTOS within National ICT Australia