From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ZMhTS-0002t2-VO for mharc-qemu-trivial@gnu.org; Tue, 04 Aug 2015 15:02:06 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMhTK-0002iE-4g for qemu-trivial@nongnu.org; Tue, 04 Aug 2015 15:02:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZMhTC-00036v-NZ for qemu-trivial@nongnu.org; Tue, 04 Aug 2015 15:01:56 -0400 Received: from hall.aurel32.net ([2001:bc8:30d7:100::1]:43024) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMhTC-00035y-HK; Tue, 04 Aug 2015 15:01:50 -0400 Received: from weber.rr44.fr ([2001:bc8:30d7:120:7e05:7ff:fe0d:f152]) by hall.aurel32.net with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZMhT8-00022r-RF; Tue, 04 Aug 2015 21:01:46 +0200 Received: from aurel32 by weber.rr44.fr with local (Exim 4.85) (envelope-from ) id 1ZMhT8-00006O-37; Tue, 04 Aug 2015 21:01:46 +0200 Date: Tue, 4 Aug 2015 21:01:46 +0200 From: Aurelien Jarno To: Alex =?iso-8859-15?Q?Benn=E9e?= Message-ID: <20150804190146.GW11361@aurel32.net> 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> <20150804115957.GA6574@aurel32.net> <87io8vkycb.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <87io8vkycb.fsf@linaro.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:bc8:30d7:100::1 Cc: qemu-trivial@nongnu.org, Paolo Bonzini , crosthwaitepeter@gmail.com, qemu-devel@nongnu.org, rth@twiddle.net Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH v4 01/11] tcg: add ability to dump /tmp/perf-.map files X-BeenThere: qemu-trivial@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 19:02:04 -0000 On 2015-08-04 13:55, Alex Benn=E9e wrote: >=20 > Aurelien Jarno writes: >=20 > > On 2015-08-04 08:39, Alex Benn=E9e wrote: > >>=20 > >> Paolo Bonzini writes: > >>=20 > >> > On 03/08/2015 11:14, Alex Benn=E9e wrote: > >> >> This allows the perf tool to map samples to each individual transla= tion > >> >> block. This could be expanded for user space but currently it gives > >> >> enough information to find any hotblocks by other means. > >> >>=20 > >> >> Signed-off-by: Alex Benn=E9e > >> > > >> > What happens if you encounter a tb_flush? > >>=20 > >> 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 buffe= r. > >> 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 flus= h? > > > > You also need to take care about TB invalidation. When the last > > generated TB is invalidated, the code pointer is rolled back to the > > end of the previous TB. In that case the last entry of the dump might > > should be replaced by the new value. If the invalidated TB is not the > > last one, it is just left in the generated code. >=20 > Can we only invalidate the previous TB and not any earlier ones? >=20 > We could keep the output line until the next TB is generated but then > you would never have a mapping for the last TB generated. I have just looked at the cde and it can (at least currently) happen only when executing with nocache, so only in icount mode. Aurelin --=20 Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMhTV-0002vo-Ha for qemu-devel@nongnu.org; Tue, 04 Aug 2015 15:02:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZMhTP-0003A2-QG for qemu-devel@nongnu.org; Tue, 04 Aug 2015 15:02:09 -0400 Date: Tue, 4 Aug 2015 21:01:46 +0200 From: Aurelien Jarno Message-ID: <20150804190146.GW11361@aurel32.net> 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> <20150804115957.GA6574@aurel32.net> <87io8vkycb.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <87io8vkycb.fsf@linaro.org> Subject: Re: [Qemu-devel] [PATCH v4 01/11] tcg: add ability to dump /tmp/perf-.map files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex =?iso-8859-15?Q?Benn=E9e?= Cc: qemu-trivial@nongnu.org, Paolo Bonzini , crosthwaitepeter@gmail.com, qemu-devel@nongnu.org, rth@twiddle.net On 2015-08-04 13:55, Alex Benn=E9e wrote: >=20 > Aurelien Jarno writes: >=20 > > On 2015-08-04 08:39, Alex Benn=E9e wrote: > >>=20 > >> Paolo Bonzini writes: > >>=20 > >> > On 03/08/2015 11:14, Alex Benn=E9e wrote: > >> >> This allows the perf tool to map samples to each individual transla= tion > >> >> block. This could be expanded for user space but currently it gives > >> >> enough information to find any hotblocks by other means. > >> >>=20 > >> >> Signed-off-by: Alex Benn=E9e > >> > > >> > What happens if you encounter a tb_flush? > >>=20 > >> 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 buffe= r. > >> 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 flus= h? > > > > You also need to take care about TB invalidation. When the last > > generated TB is invalidated, the code pointer is rolled back to the > > end of the previous TB. In that case the last entry of the dump might > > should be replaced by the new value. If the invalidated TB is not the > > last one, it is just left in the generated code. >=20 > Can we only invalidate the previous TB and not any earlier ones? >=20 > We could keep the output line until the next TB is generated but then > you would never have a mapping for the last TB generated. I have just looked at the cde and it can (at least currently) happen only when executing with nocache, so only in icount mode. Aurelin --=20 Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net