lkml.org 
[lkml]   [2016]   [Feb]   [15]   [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 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

    \
     
     \ /
      Last update: 2016-02-15 18:21    [W:2.099 / U:0.188 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site