From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42193)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZMZ3N-0000qL-B8
	for qemu-devel@nongnu.org; Tue, 04 Aug 2015 06:02:42 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZMZ3J-0002PF-Gc
	for qemu-devel@nongnu.org; Tue, 04 Aug 2015 06:02:37 -0400
References: <1438593291-27109-1-git-send-email-alex.bennee@linaro.org>
	<1438593291-27109-2-git-send-email-alex.bennee@linaro.org>
	<55BF6F68.1090103@redhat.com> <87k2tblcxq.fsf@linaro.org>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <55C08DB2.1040207@redhat.com>
Date: Tue, 4 Aug 2015 12:02:26 +0200
MIME-Version: 1.0
In-Reply-To: <87k2tblcxq.fsf@linaro.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH v4 01/11] tcg: add ability to dump
 /tmp/perf-<pid>.map files
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?UTF-8?Q?Alex_Benn=c3=a9e?= <alex.bennee@linaro.org>
Cc: qemu-trivial@nongnu.org, crosthwaitepeter@gmail.com, qemu-devel@nongnu.org, aurelien@aurel32.net, rth@twiddle.net



On 04/08/2015 09:39, Alex Benn=C3=A9e wrote:
> At the point of a tb_flush all bets are off as we will re-generate all
> the blocks at potentially different locations in the translation buffer=
.
> However for most analysis cases you are unlikely to cause the code
> buffer to overflow. Most other uses of tb_flush are the result
> debugging.
>=20
> I could add a printf when --perfmap is enabled to flag when a flush
> happens to signal to the user? I guess some more caveats in the flag
> description wouldn't hurt.
>=20
> We could consider truncating and re-starting the JIT dump at each flush=
?

Yes, it makes sense to me.  printf + truncation would work.

Paolo