lkml.org 
[lkml]   [2016]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v8 2/4] perf inject: add jitdump mmap injection support
    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?

    Unsure, please check

    > >> > static void dump_event(struct perf_evlist *evlist, union perf_event *event,
    > >> > u64 file_offset, struct perf_sample *sample)
    > >> > {
    > >> > if (sample)
    > >> > perf_evlist__print_tstamp(evlist, event, sample);
    > >> >
    > >> > printf("%#" PRIx64 " [%#x]: PERF_RECORD_%s", file_offset,
    > >> > event->header.size, perf_event__name(event->header.type));
    > >> >
    > >> > File offset, what changed?
    > >> >
    > >> As for this, the offset is not recorded in the MMAP2 record, this is
    > >> an artifact of the __perf_Session__process_events()
    > >> which passes the file_offset in the perf.data file (read by mmapping).
    > >> The offsets are changed because we inject
    > >> new mmap records, and thus the existing MMAP may be moved to a later
    > >> position in the file.
    > >>
    > >> Hope this helps.
    > >
    > > IIRC it was the missing FINISHED_ROUND, haven't checked if that was on
    > > purpose an oversight or even if so if it ends up being harmless for most
    > > workloads, have you tried this with long running or high sample freq?
    > >
    > Not yet, let me try.
    >
    > >
    > >> >
    > >> > -0x7c18 [0x8]: event: 68
    > >> > -.
    > >> > -. ... raw event: size 8 bytes
    > >> > -. 0000: 44 00 00 00 00 00 08 00 D.......
    > >> > -.
    > >> > -0x7c18 [0x8]: PERF_RECORD_FINISHED_ROUND
    > >> > -
    > >> > -0x6a80 [0x28]: event: 9
    > >> >
    > >> > Humm, inject doesn't preserves PERF_RECORD_FINISHED_ROUND? Or user events in
    > >> > general? On purpose?
    > >
    > > What about this question? Do you know? Oversight?
    > >
    > Oversight.
    >
    > I pulled tip.git and jvmti does not compile anymore for me because of
    > the alternative vs.
    > update-java-alternatives problem.
    > Is it the case that on Fedora, you do not have
    > update-java-alternatives? If so, we could
    > have the Makefile check if it exists and if not default to what you have.

    right, we need to make it test and use what is available, here:

    [root@jouet ~]# dnf search alternatives
    Last metadata expiration check performed 1:01:59 ago on Fri Feb 12
    16:38:51 2016.
    ================================================================= N/S
    Matched: alternatives
    ==================================================================
    galternatives.noarch : Alternatives Configurator
    ghc-base-unicode-symbols.x86_64 : Unicode alternatives for common
    functions and operators
    [root@jouet ~]# rpm -qf `which update-alternatives`
    chkconfig-1.7-1.fc23.x86_64
    [root@jouet ~]# rpm -ql chkconfig | grep alternativ
    /etc/alternatives
    /usr/sbin/alternatives
    /usr/sbin/update-alternatives
    /usr/share/man/man8/alternatives.8.gz
    /usr/share/man/man8/update-alternatives.8.gz
    /var/lib/alternatives

    \
     
     \ /
      Last update: 2016-02-12 22:01    [W:3.082 / U:0.172 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site