[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5dc10954-d1ad-e8f8-deff-fd237df48ecb@arm.com>
Date: Thu, 30 Mar 2023 11:36:54 +0100
From: James Clark <james.clark@....com>
To: Leo Yan <leo.yan@...aro.org>, Yang Shi <shy828301@...il.com>
Cc: linux-perf-users@...r.kernel.org,
LAK <linux-arm-kernel@...ts.infradead.org>,
coresight@...ts.linaro.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
mathieu.poirier@...aro.org, adrian.hunter@...el.com,
Jiri Olsa <jolsa@...nel.org>, acme@...hat.com,
mike.leach@...aro.org, Will Deacon <will@...nel.org>,
suzuki.poulose@....com
Subject: Re: [BUG] perf: No samples found when using kcore + coresight
On 29/03/2023 17:11, James Clark 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/@..._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/@..._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 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.
Hi Yang,
I found a temporary workaround to the issue. Whenever you use
--per-thread mode, force timeless mode when decoding with --itrace=Z and
it works the same as it did before. For example:
perf report --itrace=Zi1000i
The reason is that the new text poke event was added with timestamps
enabled. The Coresight decoder slightly incorrectly assumed that no
timestamps == per-thread mode so when it sees the new event it goes into
the wrong decode mode.
The assumption was never really correct so I will make a proper fix. But
in the mean time the workaround should be fine.
Powered by blists - more mailing lists