Re: [PATCH v2] libperf: Add API for allocating new thread map

[Jiri Olsa <olsajiri@gmail.com>]

On Wed, Feb 23, 2022 at 05:47:09PM +0200, Tzvetomir Stoyanov wrote:
> On Wed, Feb 23, 2022 at 3:03 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > On Wed, Feb 23, 2022 at 11:08:24AM +0200, Tzvetomir Stoyanov wrote:
> > > On Wed, Feb 23, 2022 at 2:21 AM Arnaldo Carvalho de Melo
> > > <arnaldo.melo@gmail.com> wrote:
> > > >
> > > > Em Tue, Feb 22, 2022 at 04:32:05AM +0200, Tzvetomir Stoyanov escreveu:
> > > > > On Mon, Feb 21, 2022 at 10:21 PM Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> > > > > > On February 21, 2022 4:46:49 PM GMT-03:00, Jiri Olsa <olsajiri@gmail.com> wrote:
> > > > > > >On Mon, Feb 21, 2022 at 12:26:28PM +0200, Tzvetomir Stoyanov (VMware) wrote:
> > > > > > >looks good, would you also find useful in your use case the comm support
> > > > > > >in thread_map? the thread_map__read_comms function? we could move it from
> > > > > > >perf to libperf
> > > >
> > > > > > IOW: we're happy that you're working on libperf, so feel encouraged
> > > > > > to move things from tools/perf/util/ to tools/lib/perf/ if you find
> > > > > > a supporting use case, brownie points if you also add an entry to
> > > > > > tools/perf/tests/, AKA 'perf test'.
> > > >
> > > > > Thanks, I see that there is a lot of functionality that could be moved
> > > > > from perf to libperf and which will be useful for the library users.
> > > > > We are going to use libperf in trace-cruncher,
> > > > > https://github.com/vmware/trace-cruncher, as an interface to perf.
> > > >
> > > > Cool, so as you go on adding functionality to trace cruncher and notice
> > > > that something that is in tools/perf/util/ that is usable, please submit
> > > > patches to move things to tools/lib/perf/, adding tests to 'perf test'
> > > > as you go.
> > > >
> > > > Thanks a lot!
> > > >
> > > > - Arnaldo
> > >
> > > Sure, I'll do it. I have one more question - do you plan to release
> > > the next version of libperf soon, so we can use this new functionality
> > > in trace-cruncher ?
> >
> > we can discuss that, can be fast ;-)
> >
> > btw I took a look on that and already put some change together,
> > please take a look and feel free to use it
> >
> > I just moved thread_map__read_comms, but I wonder we want it
> > to change to return status if it's in libperf
> >
> > jirka
> >
> 
> Thanks Jiri, I played a little with the patch but it does not fit my
> use case. It resolves only PID to command, but in my case I put
> threads in the map. How do you handle that case in perf ? I use perf
> to collect samplings from a given PID, and put all threads of this
> process in the map, all entries from /proc/PID/task/ folder. In my
> logic, as I know the PID, the commands are resolved using
> /proc/PID/task/TID/comm files.
> The other problem that I see is - there should be a way to dynamically
> resize and add new entries in the thread map. There are cases when new
> threads are spawned during the trace - these should be added in the
> thread map. In my code, I handle the PERF_RECORD_COMM event - resize
> my array and add the new entry. That can be implemented in libperf
> also, I think it will be very useful.

there's perf_thread_map__realloc, but it's not exported

> Anyway, the patch is useful for PID to command resolving, if there are
> only PIDs in the map. It could be extended with additional APIs for
> TID to command resolving. Maybe we can have these APIs:
>    void perf_thread_map__read_pid_comms(struct perf_thread_map *threads);
>    void perf_thread_map__read_tid_comms(pid_t pid, struct
> perf_thread_map *threads);

so thread_map__read_comms just resolves everything that's in the map,
so if you have thread ids in there, they should get resolved

if you expected some other functionality, like unwind pid to threads,
the thread_map__new_by_pid_str function does that

jirka