[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZEGFZmBJSzr/PIgc@kernel.org>
Date: Thu, 20 Apr 2023 15:33:10 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: James Clark <james.clark@....com>
Cc: Suzuki K Poulose <suzuki.poulose@....com>,
Ganapatrao Kulkarni <gankulkarni@...amperecomputing.com>,
mathieu.poirier@...aro.org, darren@...amperecomputing.com,
scott@...amperecomputing.com, scclevenger@...amperecomputing.com,
linux-kernel@...r.kernel.org, coresight@...ts.linaro.org,
linux-arm-kernel@...ts.infradead.org, mike.leach@...aro.org
Subject: Re: [PATCH] perf cs-etm: Add support for coresight trace for any
range of CPUs
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
Powered by blists - more mailing lists