From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R98XH-0004R6-79 for qemu-devel@nongnu.org; Thu, 29 Sep 2011 00:47:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R98XF-0005Xr-Qa for qemu-devel@nongnu.org; Thu, 29 Sep 2011 00:47:51 -0400 Received: from v220110690675601.yourvserver.net ([78.47.199.172]:60316) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R98XF-0005W4-Lv for qemu-devel@nongnu.org; Thu, 29 Sep 2011 00:47:49 -0400 Message-ID: <4E83F86B.2020208@mail.berlios.de> Date: Thu, 29 Sep 2011 06:47:39 +0200 From: Stefan Weil MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Remove line buffering from log file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Chubb Cc: bernard.blackham@nicta.com.au, qemu-devel@nongnu.org, philipo@ok-labs.com 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. That's the reason why line buffering is needed today. I enable log file output to see what happened last before the crash. It might be possible to use buffered output with a new function qemu_abort() which replaces the existing calls of abort(). This function could call flush() for the log output before aborting. In addition, SIGSEGV needs to be catched, and the signal handler would have to call flush(), too (is that possible in signal handlers?). Speed is not the primary target when somebody runs qemu -d ... Kind regards, Stefan Weil