Re: [PATCH v8 2/4] perf inject: add jitdump mmap injection support

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Sun, Feb 14, 2016 at 06:16:44PM -0800, Stephane Eranian escreveu:
> On Fri, Feb 12, 2016 at 12:43 PM, Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
> >
> > Em Fri, Feb 12, 2016 at 12:32:53PM -0800, Stephane Eranian escreveu:
> > > On Thu, Feb 11, 2016 at 2:16 PM, Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > > > Em Mon, Feb 08, 2016 at 10:53:48AM -0800, Stephane Eranian escreveu:
> > > >> > I.e. the MMAP records for the kernel modules comes in ok, humm, because
> > > >> > probably you don't hook on PERF_RECORD_MMAP in perf-inject, just on MMAP2, and
> > > >> > in those the only difference is the second field, 0x6b98 -> 0x42a0, what is
> > > >> > that?
> >
> > > >> I have both MMAP and MMAP2 hooks for the jit mode of perf inject.
> >
> > > > IIRC the different in the offsets came from 'perf inject' not preserving
> > > > FINISHED_ROUND events.
> >
> > > That's an oversight. Is there code to repipe this event already?
> >
> There is a callback for it already. But now, I remember Adrian
> suggesting, to change
> it to: perf_event__drop_oe(). In fact, if you look at builtin-inject.c
> it has a comment about
> this.

Right, IIRC that is why I asked about how big were your sessions, as
IIRC without FINISHED_ROUND we will end up having all events in memory,
so that the ordered_events can sort them, no?

The code there now is:

                inject.tool.ordered_events = true;
                inject.tool.ordering_requires_timestamps = true;
                /*
                 * JIT MMAP injection injects all MMAP events in one go, so it
                 * does not obey finished_round semantics.
                 */
                inject.tool.finished_round = perf_event__drop_oe;


Ok, there seems to be a limit there, so we end up flushing, i.e. ordering what
is in the queue and delivering the events at that limit, in
ordered_events__queue(). So it probably isn't a problem, IIRC there is even a way
to tune that queue limit, but I haven't looked at that.
 
> > right, we need to make it test and use what is available, here:

> > /usr/sbin/alternatives
 
> For me on Ubuntu:
> $ dpkg -S /usr/sbin/update-java-alternatives
> java-common: /usr/sbin/update-java-alternatives
 
> Could you check on Fedora if you do not have that package or its equivalent?

[root@jouet ~]# dnf search java-common
Last metadata expiration check performed 0:06:00 ago on Mon Feb 15
13:59:22 2016.
Error: No matches found.
[root@jouet ~]# 
[root@jouet ~]# dnf repoquery /usr/sbin/update-java-alternatives
Fedora 23 - x86_64 - Updates                          6.1 MB/s |  18 MB     00:03    
Last metadata expiration check performed 0:00:05 ago on Mon Feb 15 14:08:28 2016.
[root@jouet ~]# dnf repoquery /usr/sbin/update-alternatives
Last metadata expiration check performed 0:00:12 ago on Mon Feb 15 14:08:28 2016.
chkconfig-0:1.6-1.fc23.x86_64
chkconfig-0:1.7-1.fc23.x86_64
[root@jouet ~]# 

There is no such package (or binary) in fedora, I think we better not try to
detect the distro via packages, but just look at what of these binaries is
present, i.e. if /usr/sbin/update-java-alternatives is found, use its variant,
if not fallback to the method I used for fedora, that way we can end up
supporting other distros as a bonus.

- Arnaldo