[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YyBs1PJwNoNYv4NJ@sirena.org.uk>
Date: Tue, 13 Sep 2022 12:43:16 +0100
From: Mark Brown <broonie@...nel.org>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, peterz@...radead.org,
acme@...nel.org, mark.rutland@....com, will@...nel.org,
catalin.marinas@....com, James Clark <james.clark@....com>,
Rob Herring <robh@...nel.org>, Marc Zyngier <maz@...nel.org>,
Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH V2 3/7] arm64/perf: Update struct pmu_hw_events for BRBE
On Tue, Sep 13, 2022 at 11:03:45AM +0530, Anshuman Khandual wrote:
> On 9/12/22 15:42, Mark Brown wrote:
> > like it would be clearer and safer to allocate these dynamically
> > when BRBE is used if that's possible, I'd expect that should also
> > deal with the stack frame size issues as well.
> That might not be possible because the generic 'struct perf_branch_stack'
> expects 'perf_branch_stack.entries' to be a variable array which is also
> contiguous in memory, with other elements in 'perf_branch_stack'. Besides
> that will be a deviation from similar implementations on x86 and powerpc
> platforms.
> The stack frame size came up because BRBE_MAX_ENTRIES is 64 compared to
> just 32 on other platforms, which follow the exact same method.
If this is a pattern used by other architectures and relied on by
the core that doesn't mean it's impossible to do anything, it
means that the existing code needs to be updated to allow the
larger number of entries for BRBE if we want to change things.
That is a lot of effort of course so something that moves the
allocation off the stack would be more expedient in the short
term.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists