Thanks.I checked "perf script -D", and it contains repeated addresses in itself. The problem seems to occur at the sampling instant. Does anybody know the location of the sampling handler?
I am looking forward to the answer. Regards. On 2020-03-31 20:40, Arnaldo Carvalho de Melo wrote:
Em Tue, Mar 31, 2020 at 05:29:17PM +0200, Milian Wolff escreveu: On Dienstag, 31. März 2020 17:02:37 CEST ahmadkhorrami wrote: Hi Milian, Thanks for the detailed answer. Well, the bug you mentioned is bad news.Because I sample using uppp. Perhaps this leads to these weird traces. Please read the full thread from here on: https://lkml.org/lkml/2018/11/2/86But as I said - it should be easy to check if this is really the issue are running into or not: Try to see if you see the problem when you sample without `ppp`. If not, then you can be pretty sure it's this issue. If you still seeit, then it's something different. Is this a purely software bug?I wouldn't call it that, personally. Rather, it's a limitation in the hardware and software. We would need something completely different to "fix" this, i.e. something like a deeper LBR. That's btw another alternative you could try: `perf record --call-graph lbr` and live with the short call stacks. But at least these should be correct (afaik). For me personally they are always fartoo short and thus not practical to use in reality.
Probably this may help: From: Kan Liang <kan.liang@xxxxxxxxxxxxxxx> Subject: [PATCH V4 00/17] Stitch LBR call stack (Perf Tools) Date: Thu, 19 Mar 2020 13:25:00 -0700https://lore.kernel.org/lkml/20200319202517.23423-1-kan.liang@xxxxxxxxxxxxxxx/
- Arnaldo
|