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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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