Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1332418 > unrolled thread

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

Started byArnaldo Carvalho de Melo <acme@kernel.org>
First post2016-02-12 00:00 +0100
Last post2016-02-15 18:20 +0100
Articles 5 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v8 2/4] perf inject: add jitdump mmap injection support Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-02-12 00:00 +0100
    Re: [PATCH v8 2/4] perf inject: add jitdump mmap injection support Stephane Eranian <eranian@google.com> - 2016-02-12 21:40 +0100
      Re: [PATCH v8 2/4] perf inject: add jitdump mmap injection support Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-02-12 21:50 +0100
        Re: [PATCH v8 2/4] perf inject: add jitdump mmap injection support Stephane Eranian <eranian@google.com> - 2016-02-15 03:20 +0100
          Re: [PATCH v8 2/4] perf inject: add jitdump mmap injection support Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-02-15 18:20 +0100

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

FromArnaldo Carvalho de Melo <acme@kernel.org>
Date2016-02-12 00:00 +0100
SubjectRe: [PATCH v8 2/4] perf inject: add jitdump mmap injection support
Message-ID<r18no-6Ne-11@gated-at.bofh.it>
Em Mon, Feb 08, 2016 at 10:53:48AM -0800, Stephane Eranian escreveu:
> Hi Arnaldo,
> 
> Sorry for the delay, I missed your message.
> 
> I tried with openjdk-8 on Ubuntu/Wily and I do not get the crash using
> the same hello world test program.
> In fact, if I print file_name, it is never NULL for me.

All this is already upstream, in tip.git, Ingo merged those patches.

There were still some open questions tho, that I listed on the changelog
comments.

See below for some more things
 
> $ java -agentpath:/home/eranian/tip/tools/perf/jvmti/libjvmti.so hello
> java: jvmti: jitdump in
> /home/eranian/.debug/jit/java-jit-20160208.XX8wCwyY/jit-20156.dump
> java: FILE_NAME: Object.java
> java: FILE_NAME: String.java
> java: FILE_NAME: String.java
> java: FILE_NAME: String.java
> java: FILE_NAME: String.java
> java: FILE_NAME: String.java
> java: FILE_NAME: System.java
> java: FILE_NAME: Math.java
> java: FILE_NAME: Object.java
> java: FILE_NAME: Reference.java
> java: FILE_NAME: AbstractStringBuilder.java
> java: FILE_NAME: ThreadLocal.java
> java: FILE_NAME: AbstractStringBuilder.java
> java: FILE_NAME: String.java
> Hello, World
> 
> So I am not sure what is different in your setup especially if the
> function GetSourceFileName() did not fail.
> Could you print file_name in your code to check?

will try and do it after replying to the other parts of this message,
the patch that went upstream checks it in any case.
 
> 
> As for the MMAP, it is normal to have the extra mmaps pointing to the
> jitted code.
> Event for a simple program as hello world, there are several function
> jitted, including the
> java interpreter itself. There is one MMAP for each jitted function.

Ok, tons of ELF files, wonder if having just one would be better, but
that would be an improvement, not a requirement, I guess.
 
> On Fri, Feb 5, 2016 at 6:24 AM, Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
> >
> > Em Fri, Feb 05, 2016 at 10:57:17AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Duh:
> > >
> > > [acme@jouet java]$ java -agentpath:/home/acme/git/linux/tools/perf/jvmti/libjvmti.so hello
> > > java: jvmti: jitdump in /home/acme/.debug/jit/java-jit-20160205.XXFb472a/jit-28966.dump
> > > Hello, World
> > > [acme@jouet java]$
> >
> > Ok, so mucho progress:
> >
> > [acme@jouet java]$ perf record -k 1 java -agentpath:/home/acme/git/linux/tools/perf/jvmti/libjvmti.so hello
> > java: jvmti: jitdump in /home/acme/.debug/jit/java-jit-20160205.XXIiqiq7/jit-31400.dump
> > Hello, World
> > [ perf record: Woken up 1 times to write data ]
> > [ perf record: Captured and wrote 0.030 MB perf.data (268 samples) ]
> > [acme@jouet java]$ perf inject --jit -i perf.data -o perf.data.jitted
> > [acme@jouet java]$ perf report -D -i perf.data | grep PERF_RECORD_MMAP > mmaps.before
> > Failed to open /tmp/perf-31400.map, continuing without symbols
> > [acme@jouet java]$ perf report -D -i perf.data. | grep PERF_RECORD_MMAP > mmaps.before
> > perf.data.jitted      perf.data.jitted.old  perf.data.old
> > [acme@jouet java]$ perf report -D -i perf.data.jitted | grep PERF_RECORD_MMAP > mmaps.jitted
> > [acme@jouet java]$ diff -u mmaps.before mmaps.jitted
> > --- mmaps.before        2016-02-05 11:01:16.019257683 -0300
> > +++ mmaps.jitted        2016-02-05 11:01:28.966232802 -0300
> > <SNIP>
> > +77539479986521 0xfc80 [0xa0]: PERF_RECORD_MMAP2 31400/31413: [0x7f3f7d102880(0xc0) @ 0x40 fd:02 1840179 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXIiqiq7/jitted-31400-281.so
> > +77539480189814 0xfd20 [0xa0]: PERF_RECORD_MMAP2 31400/31413: [0x7f3f7d0fef60(0x80) @ 0x40 fd:02 1840180 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXIiqiq7/jitted-31400-282.so
> > +77539480541065 0xfdc0 [0xa0]: PERF_RECORD_MMAP2 31400/31413: [0x7f3f7d102560(0x180) @ 0x40 fd:02 1840181 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXIiqiq7/jitted-31400-283.so
> > +77539480541871 0xfe60 [0xa0]: PERF_RECORD_MMAP2 31400/31413: [0x7f3f7d102360(0x180) @ 0x40 fd:02 1840182 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXIiqiq7/jitted-31400-284.so
> > +77539480848667 0xff00 [0xa0]: PERF_RECORD_MMAP2 31400/31413: [0x7f3f7d102160(0x180) @ 0x40 fd:02 1840183 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXIiqiq7/jitted-31400-285.so
> > +77539480910925 0xffa0 [0xa0]: PERF_RECORD_MMAP2 31400/31413: [0x7f3f7d101f60(0x180) @ 0x40 fd:02 1840184 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXIiqiq7/jitted-31400-286.so
> > <SNIP>
> >
> > Quite a lot of those, but I noticed this, probably harmless, at the start:
> >
> >  0 0x3fd8 [0x88]: PERF_RECORD_MMAP -1/0: [0xffffffffa0991000(0x5000) @ 0]: x /lib/modules/4.3.4-300.fc23.x86_64/kernel/net/dns_resolver/dns_resolver.ko.xz
> >  0 0x4060 [0x78]: PERF_RECORD_MMAP -1/0: [0xffffffffa0996000(0x7b000) @ 0]: x /lib/modules/4.3.4-300.fc23.x86_64/kernel/fs/nfs/nfsv4.ko.xz
> >  0 0x40d8 [0x88]: PERF_RECORD_MMAP -1/0: [0xffffffffa0a11000(0x5f5eefff) @ 0]: x /lib/modules/4.3.4-300.fc23.x86_64/kernel/drivers/usb/storage/usb-storage.ko.xz
> > -77539437123281 0x6b98 [0xa0]: PERF_RECORD_MMAP2 31400/31400: [0x557b73152000(0x202000) @ 0 fd:00 7858 3897326142]: r-xp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.71-1.b15.fc23.x86_64/jre/bin/java
> > +77539437123281 0x42a0 [0xa0]: PERF_RECORD_MMAP2 31400/31400: [0x557b73152000(0x202000) @ 0 fd:00 7858 3897326142]: r-xp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.71-1.b15.fc23.x86_64/jre/bin/java
> >
> > 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.
 
> > 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?

 
> >
> > -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?

- Arnaldo

[toc] | [next] | [standalone]

#1333086

FromStephane Eranian <eranian@google.com>
Date2016-02-12 21:40 +0100
Message-ID<r1sFr-3t7-7@gated-at.bofh.it>
In reply to#1332418
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:
>> Hi Arnaldo,
>>
>> Sorry for the delay, I missed your message.
>>
>> I tried with openjdk-8 on Ubuntu/Wily and I do not get the crash using
>> the same hello world test program.
>> In fact, if I print file_name, it is never NULL for me.
>
> All this is already upstream, in tip.git, Ingo merged those patches.
>
> There were still some open questions tho, that I listed on the changelog
> comments.
>
> See below for some more things
>
>> $ java -agentpath:/home/eranian/tip/tools/perf/jvmti/libjvmti.so hello
>> java: jvmti: jitdump in
>> /home/eranian/.debug/jit/java-jit-20160208.XX8wCwyY/jit-20156.dump
>> java: FILE_NAME: Object.java
>> java: FILE_NAME: String.java
>> java: FILE_NAME: String.java
>> java: FILE_NAME: String.java
>> java: FILE_NAME: String.java
>> java: FILE_NAME: String.java
>> java: FILE_NAME: System.java
>> java: FILE_NAME: Math.java
>> java: FILE_NAME: Object.java
>> java: FILE_NAME: Reference.java
>> java: FILE_NAME: AbstractStringBuilder.java
>> java: FILE_NAME: ThreadLocal.java
>> java: FILE_NAME: AbstractStringBuilder.java
>> java: FILE_NAME: String.java
>> Hello, World
>>
>> So I am not sure what is different in your setup especially if the
>> function GetSourceFileName() did not fail.
>> Could you print file_name in your code to check?
>
> will try and do it after replying to the other parts of this message,
> the patch that went upstream checks it in any case.
>
>>
>> As for the MMAP, it is normal to have the extra mmaps pointing to the
>> jitted code.
>> Event for a simple program as hello world, there are several function
>> jitted, including the
>> java interpreter itself. There is one MMAP for each jitted function.
>
> Ok, tons of ELF files, wonder if having just one would be better, but
> that would be an improvement, not a requirement, I guess.
>
>> On Fri, Feb 5, 2016 at 6:24 AM, Arnaldo Carvalho de Melo
>> <acme@kernel.org> wrote:
>> >
>> > Em Fri, Feb 05, 2016 at 10:57:17AM -0300, Arnaldo Carvalho de Melo escreveu:
>> > > Duh:
>> > >
>> > > [acme@jouet java]$ java -agentpath:/home/acme/git/linux/tools/perf/jvmti/libjvmti.so hello
>> > > java: jvmti: jitdump in /home/acme/.debug/jit/java-jit-20160205.XXFb472a/jit-28966.dump
>> > > Hello, World
>> > > [acme@jouet java]$
>> >
>> > Ok, so mucho progress:
>> >
>> > [acme@jouet java]$ perf record -k 1 java -agentpath:/home/acme/git/linux/tools/perf/jvmti/libjvmti.so hello
>> > java: jvmti: jitdump in /home/acme/.debug/jit/java-jit-20160205.XXIiqiq7/jit-31400.dump
>> > Hello, World
>> > [ perf record: Woken up 1 times to write data ]
>> > [ perf record: Captured and wrote 0.030 MB perf.data (268 samples) ]
>> > [acme@jouet java]$ perf inject --jit -i perf.data -o perf.data.jitted
>> > [acme@jouet java]$ perf report -D -i perf.data | grep PERF_RECORD_MMAP > mmaps.before
>> > Failed to open /tmp/perf-31400.map, continuing without symbols
>> > [acme@jouet java]$ perf report -D -i perf.data. | grep PERF_RECORD_MMAP > mmaps.before
>> > perf.data.jitted      perf.data.jitted.old  perf.data.old
>> > [acme@jouet java]$ perf report -D -i perf.data.jitted | grep PERF_RECORD_MMAP > mmaps.jitted
>> > [acme@jouet java]$ diff -u mmaps.before mmaps.jitted
>> > --- mmaps.before        2016-02-05 11:01:16.019257683 -0300
>> > +++ mmaps.jitted        2016-02-05 11:01:28.966232802 -0300
>> > <SNIP>
>> > +77539479986521 0xfc80 [0xa0]: PERF_RECORD_MMAP2 31400/31413: [0x7f3f7d102880(0xc0) @ 0x40 fd:02 1840179 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXIiqiq7/jitted-31400-281.so
>> > +77539480189814 0xfd20 [0xa0]: PERF_RECORD_MMAP2 31400/31413: [0x7f3f7d0fef60(0x80) @ 0x40 fd:02 1840180 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXIiqiq7/jitted-31400-282.so
>> > +77539480541065 0xfdc0 [0xa0]: PERF_RECORD_MMAP2 31400/31413: [0x7f3f7d102560(0x180) @ 0x40 fd:02 1840181 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXIiqiq7/jitted-31400-283.so
>> > +77539480541871 0xfe60 [0xa0]: PERF_RECORD_MMAP2 31400/31413: [0x7f3f7d102360(0x180) @ 0x40 fd:02 1840182 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXIiqiq7/jitted-31400-284.so
>> > +77539480848667 0xff00 [0xa0]: PERF_RECORD_MMAP2 31400/31413: [0x7f3f7d102160(0x180) @ 0x40 fd:02 1840183 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXIiqiq7/jitted-31400-285.so
>> > +77539480910925 0xffa0 [0xa0]: PERF_RECORD_MMAP2 31400/31413: [0x7f3f7d101f60(0x180) @ 0x40 fd:02 1840184 1]: --xs /home/acme/.debug/jit/java-jit-20160205.XXIiqiq7/jitted-31400-286.so
>> > <SNIP>
>> >
>> > Quite a lot of those, but I noticed this, probably harmless, at the start:
>> >
>> >  0 0x3fd8 [0x88]: PERF_RECORD_MMAP -1/0: [0xffffffffa0991000(0x5000) @ 0]: x /lib/modules/4.3.4-300.fc23.x86_64/kernel/net/dns_resolver/dns_resolver.ko.xz
>> >  0 0x4060 [0x78]: PERF_RECORD_MMAP -1/0: [0xffffffffa0996000(0x7b000) @ 0]: x /lib/modules/4.3.4-300.fc23.x86_64/kernel/fs/nfs/nfsv4.ko.xz
>> >  0 0x40d8 [0x88]: PERF_RECORD_MMAP -1/0: [0xffffffffa0a11000(0x5f5eefff) @ 0]: x /lib/modules/4.3.4-300.fc23.x86_64/kernel/drivers/usb/storage/usb-storage.ko.xz
>> > -77539437123281 0x6b98 [0xa0]: PERF_RECORD_MMAP2 31400/31400: [0x557b73152000(0x202000) @ 0 fd:00 7858 3897326142]: r-xp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.71-1.b15.fc23.x86_64/jre/bin/java
>> > +77539437123281 0x42a0 [0xa0]: PERF_RECORD_MMAP2 31400/31400: [0x557b73152000(0x202000) @ 0 fd:00 7858 3897326142]: r-xp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.71-1.b15.fc23.x86_64/jre/bin/java
>> >
>> > 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?

>> > 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.

Thanks.

[toc] | [prev] | [next] | [standalone]

#1333089

FromArnaldo Carvalho de Melo <acme@kernel.org>
Date2016-02-12 21:50 +0100
Message-ID<r1sP7-3ws-1@gated-at.bofh.it>
In reply to#1333086
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

[toc] | [prev] | [next] | [standalone]

#1334105

FromStephane Eranian <eranian@google.com>
Date2016-02-15 03:20 +0100
Message-ID<r2gVA-2Vi-11@gated-at.bofh.it>
In reply to#1333089
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, 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


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?

[toc] | [prev] | [next] | [standalone]

#1334624

FromArnaldo Carvalho de Melo <acme@kernel.org>
Date2016-02-15 18:20 +0100
Message-ID<r2uYy-41S-29@gated-at.bofh.it>
In reply to#1334105
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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web