On 2015-08-04 13:55, Alex Bennée wrote: > > Aurelien Jarno <aurel...@aurel32.net> writes: > > > On 2015-08-04 08:39, Alex Bennée wrote: > >> > >> Paolo Bonzini <pbonz...@redhat.com> writes: > >> > >> > On 03/08/2015 11:14, Alex Bennée wrote: > >> >> This allows the perf tool to map samples to each individual translation > >> >> block. This could be expanded for user space but currently it gives > >> >> enough information to find any hotblocks by other means. > >> >> > >> >> Signed-off-by: Alex Bennée <alex.ben...@linaro.org> > >> > > >> > What happens if you encounter a tb_flush? > >> > >> 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. > >> > >> 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. > >> > >> We could consider truncating and re-starting the JIT dump at each flush? > > > > 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. > > Can we only invalidate the previous TB and not any earlier ones? > > 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 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
