On Wed, 2015-09-30 at 14:33 +0530, Anshuman Khandual wrote: > On 07/28/2015 08:38 AM, Anshuman Khandual wrote: > > On 07/27/2015 09:49 AM, Michael Ellerman wrote: > >> > On Tue, 2015-30-06 at 08:20:27 UTC, Anshuman Khandual wrote: > >>> >> BHRB (Branch History Rolling Buffer) is a rolling buffer. Hence we > >>> >> might end up in a situation where we have read one target address > >>> >> but when we try to read the next entry indicating the from address > >>> >> of the target address, the buffer just overflows. In this case, the > >>> >> captured from address will be zero which indicates the end of the > >>> >> buffer. > >> > > >> > Right. But with SMT8 the size of the buffer is very small, so we will > >> > actually > >> > hit this case somewhat often. When we originally wrote this we decided > >> > it was > >> > better to get some information, ie. the from address, than no > >> > information at > >> > all. > > You are right. But practically as of now we are not using this kind of > > (from, 0) branch entries any where as a special case. More over for > > certain kind of workloads which has a small code and a few branches, > > the chances of getting this kind of branch (from, 0) increases a lot > > making them probably one of the highest percentage entries in the final > > perf report. Now with this change of code, the workload session might > > have overall less number of branch entries, but in my opinion represents > > more accurate branch profile of the given workload in percentage wise. > > > >> > > >>> >> This patch drops the entire branch record which would have > >>> >> otherwise confused the user space tools. > >> > > >> > Does it confuse the tools? Can you show me before/after output from perf? > > The word 'confuse' might be little misleading. But the point as > > explained above that the relative branch percentage profile of > > certain workloads might be distorted and that I believe is true. > > Also branch entries like "from ----> 0" in the perf report might > > be confusing to users who dont expect to see this kind of entries > > in the final perf report and will never get into "perf report -D" > > to figure out what really happened. > > Hey Michael, > > As I had explained earlier, is not it a good idea to drop these > kind of branch records from the final output ? I will request > consideration of this patch along with others in the series.
I think it's too late to change it. ie. we've shipped several kernel versions that did emit them, so we just have to stick with that. If it was obviously a bug fix we could change it, but it's not obviously correct either way. So please drop that patch and repost the series. cheers _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
