On Mon, Aug 29, 2022 at 12:21 AM Song Liu <songliubraving@xxxxxx> wrote: > > > > > On Aug 26, 2022, at 11:25 PM, Namhyung Kim <namhyung@xxxxxxxxxx> wrote: > > > > On Fri, Aug 26, 2022 at 2:26 PM Song Liu <songliubraving@xxxxxx> wrote: > >> > >> > >> > >>> On Aug 26, 2022, at 2:12 PM, Namhyung Kim <namhyung@xxxxxxxxxx> wrote: > >>> > >>> On Fri, Aug 26, 2022 at 1:59 PM Song Liu <songliubraving@xxxxxx> wrote: > >>>> > >>>> > >>>> > >>>>> On Aug 26, 2022, at 12:30 PM, Namhyung Kim <namhyung@xxxxxxxxxx> wrote: > >>>>> > >>>>> On Fri, Aug 26, 2022 at 11:45 AM Song Liu <songliubraving@xxxxxx> 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
