lkml.org 
[lkml]   [2022]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH bpf-next] bpf: Add bpf_read_raw_record() helper
On Mon, Aug 29, 2022 at 12:21 AM Song Liu <songliubraving@fb.com> wrote:
>
>
>
> > On Aug 26, 2022, at 11:25 PM, Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > On Fri, Aug 26, 2022 at 2:26 PM Song Liu <songliubraving@fb.com> wrote:
> >>
> >>
> >>
> >>> On Aug 26, 2022, at 2:12 PM, Namhyung Kim <namhyung@kernel.org> wrote:
> >>>
> >>> On Fri, Aug 26, 2022 at 1:59 PM Song Liu <songliubraving@fb.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>>> On Aug 26, 2022, at 12:30 PM, Namhyung Kim <namhyung@kernel.org> wrote:
> >>>>>
> >>>>> On Fri, Aug 26, 2022 at 11:45 AM Song Liu <songliubraving@fb.com> wrote:
> >>>>>
> >>>>>>> And actually, we can just read ctx->data and get the raw record,
> >>>>>>> right..?
> >>>>>>
> >>>>>> Played with this for a little bit. ctx->data appears to be not
> >>>>>> reliable sometimes. I guess (not 100% sure) this is because we
> >>>>>> call bpf program before event->orig_overflow_handler. We can
> >>>>>> probably add a flag to specify we want to call orig_overflow_handler
> >>>>>> first.
> >>>>>
> >>>>> I'm not sure. The sample_data should be provided by the caller
> >>>>> of perf_event_overflow. So I guess the bpf program should see
> >>>>> a valid ctx->data.
> >>>>
> >>>> Let's dig into this. Maybe we need some small changes in
> >>>> pe_prog_convert_ctx_access.
> >>>
> >>> Sure, can you explain the problem in detail and share your program?
> >>
> >> I push the code to
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/song/linux.git/log/?h=test-perf-event
> >>
> >> The code is in tools/bpf/perf-test/.
> >>
> >> The problem is we cannot get reliable print of data->cpu_entry in
> >> /sys/kernel/tracing/trace.
> >
> > Ah, right. I've realized that the sample data is passed before full
> > initialized. Please see perf_sample_data_init(). The other members
> > are initialized right before written to the ring buffer in the
> > orig_overflow_handler (__perf_event_output).
> >
> > That explains why pe_prog_convert_ctx_access() handles
> > data and period specially. We need to handle it first.
>
> Thanks for confirming this. I guess we will need a helper (or kfunc)
> for the raw data.
>
> Shall we make it more generic that we can get other PERF_SAMPLE_*?

I don't think we can (or allow to) get all the sample data but some
would be useful for filtering. Currently I'm only interested in the raw
data, but ip and page size seem useful too.

So I think it'd be better to have a generic helper rather than a specific
one. But it'd require some refactoring to get the data before calling
BPF programs. Let me work on it first.

Thanks,
Namhyung

\
 
 \ /
  Last update: 2022-08-29 22:12    [W:1.227 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site