qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Remove line buffering from log file


From: Peter Chubb
Subject: Re: [Qemu-devel] [PATCH] Remove line buffering from log file
Date: Thu, 29 Sep 2011 15:03:53 +1000
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.8 Emacs/23.3 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

>>>>> "Stefan" == Stefan Weil <address@hidden> 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 <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]