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
> <[email protected]> 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
> > > <[email protected]> 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
