[PATCH V8 01/10] powerpc, perf: Drop the branch sample when 'from' cannot be fetched

[Daniel Axtens]

Hi,

On Wed, 2015-06-10 at 17:32 +0530, Anshuman Khandual wrote:
> On 06/10/2015 08:51 AM, Daniel Axtens wrote:
> > Hi Anshuman,
> > 
> > Was there a cover letter for this series that I missed?
> 
> This is the continuation (rebased and reworked) of the series
> posted at https://lkml.org/lkml/2014/5/5/153 (which is V6). I
> remember to have incremented the count for the re-send of the
> first four patches of the series to Peter Z for generic review
> which got pulled in last year. These patches here are the
> remaining powerpc part of the original series. Will list down
> the current changes as well next time around along with the new
> ones.
> 
> > 
> > On Mon, 2015-06-08 at 17:08 +0530, Anshuman Khandual wrote:
> >> BHRB is a rolling buffer. Hence we might end up in a situation where
> > Could you spell out what BHRB stands for?
> 
> Branch History Rolling Buffer, would you like to have that in the
> commit message as well ?
Yes please.
> 
> > 
> >> we have read one target address but when we try to read the next entry
> >>  indicating the from address of the targe, the buffer just overflows.
> > target?
> 
> Yeah its target address.
Ok, I was just trying to point out the spelling mistake above.
> 
> > 
> >> In this case, the captured from address will be zero which indicates
> >> the end of the buffer.
> >>
> > In what sort of situations would this occur? It seems like something we
> > would want to avoid if possible?
> 
> Its not avoidable. During regular flow of branch recording, the HW would
> have written both the records correctly but then the new ones came in and
> we just happen to loose one of them causing this situation.
OK.

Regards,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 860 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20150611/605723f2/attachment.sig>