Re: [PATCH] perf cs-etm: Add support for coresight trace for any range of CPUs

[Arnaldo Carvalho de Melo]

Em Thu, Apr 20, 2023 at 04:44:21PM +0100, James Clark escreveu:
> On 20/04/2023 14:03, Suzuki K Poulose wrote:
> > On 20/04/2023 13:37, Ganapatrao Kulkarni wrote:
> >> On 20-04-2023 06:00 pm, James Clark wrote:
> >>> On 20/04/2023 12:47, Ganapatrao Kulkarni wrote:
> >>>> My patch is rebased on 6.3-RC7 codebase with Mike's 3 perf patches
> >>>> related to dynamic id [1] support(queued for 6.4).

> >>>> "perf report -D" works for me.

> >>> I was referring to sparse CPU lists, which I think you mentioned above
> >>> doesn't work even with this patch.

> >>>> [1] https://www.spinics.net/lists/linux-perf-users/msg27452.html

> >>> It should be based on the next branch here:
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git

> >> OK.

> > It need not be. Since this patch is purely perf tools patch and has
> > nothing to do with the kernel drivers, it should be beased on whatever
> > the tip of the perf tool tree is. Otherwise we risk rebasing to that
> > eventually.

> Good point, sorry for the confusion!
 
> I wonder if we could have some kind of new staging branch that has both
> up to date perf and coresight changes at the same time? Either that
> would make things like this easier, or more complicated. I'm not sure.
 
> I suppose I can DIY it quite easily but then everyone would have to as well.

My two cents: It this was available together with a CI that would run
'perf test' + 'make -C tools/perf build-test' and any other set of
tests, that would be great.

But not having it also has an advantage: no lockstep development,
tooling should gracefully work with whatever is available.

I say this because it is a really common theme, even Debian had a
packaging scheme that shoehorned (forcefully fused?) perf's and the
kernel's version :-\

- Arnaldo