Messages in this thread | | | Date | Thu, 30 Mar 2023 09:17:52 +0100 | Subject | Re: [BUG] perf: No samples found when using kcore + coresight | From | James Clark <> |
| |
On 30/03/2023 00:25, Yang Shi wrote: > On Wed, Mar 29, 2023 at 9:08 AM James Clark <james.clark@arm.com> wrote: >> >> >> >> On 14/03/2023 00:36, Leo Yan wrote: >>> On Mon, Mar 13, 2023 at 11:15:44AM -0700, Yang Shi wrote: >>> >>> [...] >>> >>>>> Just a quick summary, here we have two issues: >>>>> >>>>> - With command: >>>>> perf record -e cs_etm/@tmc_etf63/k --kcore --per-thread \ >>>>> -- taskset --cpu-list 1 uname", >>>>> >>>>> perf doesn't enable "text poke" attribution. >>>> >>>> No, it enables "text poke" and perf fails to decode coresight trace >>>> data too. It doesn't matter whether "--kcore" is after or before "-e >>>> cs/etm/@tmc_etf63/k". >>> >>> Understand now. Thanks for correction, if so we can ignore this one. >>> >>> Leo >> >> To me it looks like it's only --per-thread and --kcore together that >> cause the issue. I can't see if that was mentioned previously in this >> thread. > > If "--pre-thread" is not passed in, perf record failed with "failed to > mmap with 12 (Cannot allocate memory)". Sorry for not mentioning this > in the first place. I was quite focused on --kcore and didn't realize > they may be related.
That's unrelated. That's because you have specified a sink and without --per-thread it tries to open the event on all cores. If the sink can't be reached from all cores it will fail to open. You can make it work without --per-thread if you limit it to a valid core like this, although I don't know which ones exactly would be valid for your system:
perf record -e cs_etm/@tmc_etf63/k --kcore -C 0 \ -- taskset --cpu-list 1 uname
> >> >> If it is --per-thread that's causing the issue then I think I have an >> idea why it might be. There are some assumptions and different paths >> taken in decoding in that mode that aren't correct. It causes some other >> issues to do with ordering and timestamps as well and I wanted to fix it >> previously. I wouldn't say that the text-poke change has caused a >> regression, as decoding in this mode was always a bit buggy. >> >> Maybe this is another reason to fix it properly.
| |