[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YR6ih+pKSm5TVVBc@hirez.programming.kicks-ass.net>
Date: Thu, 19 Aug 2021 20:27:19 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Song Liu <songliubraving@...com>
Cc: "open list:BPF (Safe dynamic programs and tools)"
<bpf@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"acme@...nel.org" <acme@...nel.org>,
"mingo@...hat.com" <mingo@...hat.com>,
Kernel Team <Kernel-team@...com>,
Kan Liang <kan.liang@...ux.intel.com>,
Like Xu <like.xu@...ux.intel.com>,
Alexey Budankov <alexey.budankov@...ux.intel.com>
Subject: Re: [RFC] bpf: lbr: enable reading LBR from tracing bpf programs
On Thu, Aug 19, 2021 at 06:22:07PM +0000, Song Liu wrote:
> > And if we're going to be adding new pmu::methods then I figure one that
> > does the whole sample state might be more useful.
>
> What do you mean by "whole sample state"? To integrate with exiting
> perf_sample_data, like perf_output_sample()?
Yeah, the PMI can/does set more than data->br_stack, but I'm now
thinking that without an actual PMI, much of that will not be possible.
br_stack is special here.
Oh well, carry on I suppose.
Powered by blists - more mailing lists