[Top][All Lists]
[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