Will,
Problem fixed in the git tree. Was a broken implementation of the
cgroupfs_find_mountpoint(). So I reused the one from syst_count.c.
Let me know if it works again on Fedora now.
Thanks for reporting the problem.
On Mon, Jan 26, 2015 at 9:01 AM, William Cohen <wco...@redhat.com> wrote:
> On 01/26/2015 11:11 AM, Stephane Eranian wrote:
>> On Tue, Jan 20, 2015 at 7:55 PM, William Cohen <wco...@redhat.com> wrote:
>>> I have been experimenting with the libpfm4 perf_example syst_smpl.c
>>> and syst_count.c on a fedora 21. The syst_count executable seems to
>>> work fine with the "-G" (cgroup) option, but the similar syst_smpl
>>> does not seems to work with "-G" option. Is there a know issue with
>>> syst_smpl? Below is the detailed output and comments.
>>>
>>> -Will
>>>
>>> #version of the kernel
>>> [wcohen@santana perf_examples]$ uname -a
>>> Linux santana 3.17.8-300.fc21.x86_64 #1 SMP Thu Jan 8 23:32:49 UTC 2015
>>> x86_64 x86_64 x86_64 GNU/Linux
>>>
>>>
>>> #the syst_count works fine with "-G"
>>> [wcohen@santana perf_examples]$ sudo ./syst_count -e
>>> instructions:period=1000000 -G
>>> machine.slice/machine-qemu\\x2drawhide\\x2dx86_64.scope
>>> <press CTRL-C to quit before 20s time limit>
>>> # -----
>>> CPU0 G0 12,772,904 12,772,904
>>> instructions:period=1000000 (scaling 0.00%, ena=24,464,661, run=24,464,661)
>>> machine.slice/machine-qemu\x2drawhide\x2dx86_64.scope
>>> # -----
>>> CPU1 G0 0 0
>>> instructions:period=1000000 (scaling 100.00%, ena=0, run=0)
>>> machine.slice/machine-qemu\x2drawhide\x2dx86_64.scope
>>> # -----
>>> CPU2 G0 20,742,080 20,742,080
>>> instructions:period=1000000 (scaling 0.00%, ena=33,956,028, run=33,956,028)
>>> machine.slice/machine-qemu\x2drawhide\x2dx86_64.scope
>>> # -----
>>> CPU3 G0 0 0
>>> instructions:period=1000000 (scaling 100.00%, ena=0, run=0)
>>> machine.slice/machine-qemu\x2drawhide\x2dx86_64.scope
>>> # -----
>>> CPU4 G0 16,856,036 16,856,036
>>> instructions:period=1000000 (scaling 0.00%, ena=32,670,860, run=32,670,860)
>>> machine.slice/machine-qemu\x2drawhide\x2dx86_64.scope
>>> # -----
>>> CPU5 G0 12,021,365 12,021,365
>>> instructions:period=1000000 (scaling 0.00%, ena=18,781,042, run=18,781,042)
>>> machine.slice/machine-qemu\x2drawhide\x2dx86_64.scope
>>> # -----
>>> CPU6 G0 18,757,928 18,757,928
>>> instructions:period=1000000 (scaling 0.00%, ena=35,832,328, run=35,832,328)
>>> machine.slice/machine-qemu\x2drawhide\x2dx86_64.scope
>>> # -----
>>> CPU7 G0 0 0
>>> instructions:period=1000000 (scaling 100.00%, ena=0, run=0)
>>> machine.slice/machine-qemu\x2drawhide\x2dx86_64.scope
>>>
>>> #the similar syst_smpl fails with the same arguments
>>> [wcohen@santana perf_examples]$ sudo ./syst_smpl -e
>>> instructions:period=1000000 -G
>>> machine.slice/machine-qemu\\x2drawhide\\x2dx86_64.scope
>>> instructions:period=1000000 period=1000000 freq=0
>>> syst_smpl: cannot attach event instructions:period=1000000: No such file or
>>> directory
>>>
>>> #remove the "-G" option and it works
>>> [wcohen@santana perf_examples]$ sudo ./syst_smpl -e
>>> instructions:period=1000000
>>> instructions:period=1000000 period=1000000 freq=0
>>> monitoring on CPU7, session ending in 10s
>>> IIP:0xffffffff811ba233 PID:4518 TID:4518 TIME:564,850,150,917,372
>>> STREAM_ID:12046 CPU:7 PERIOD:1,000,000 ENA=2,971,666,279 RUN=2,971,666,279
>>> 1,000,309 instructions:period=1000000
>>>
>>> IIP:0xffffffff8139cfde PID:4520 TID:4520 TIME:564,850,175,258,219
>>> STREAM_ID:12046 CPU:7 PERIOD:1,000,000 ENA=2,996,007,161 RUN=2,996,007,161
>>> 2,000,325 instructions:period=1000000
>>>
>>> IIP:0xffffffff811cd437 PID:4522 TID:4522 TIME:564,850,176,382,739
>>> STREAM_ID:12046 CPU:7 PERIOD:1,000,000 ENA=2,997,130,740 RUN=2,997,130,740
>>> 3,000,340 instructions:period=1000000
>>>
>>> IIP:0xffffffff811ba61d PID:4525 TID:4525 TIME:564,850,198,925,823
>>> STREAM_ID:12046 CPU:7 PERIOD:1,000,000 ENA=3,019,673,686 RUN=3,019,673,686
>>> 4,000,287 instructions:period=1000000
>>>
>>> 4 samples collected in 0 poll events, 0 lost samples
>>>
>> Do not have a good explanation for this yet given the code looks
>> similar in the two programs. Could you send me the strace output
>> for syst_smpl. And which kernel version are you running?
>
> Hi Stephane,
>
> The machine is an x86_64 fedora21 machine:
>
> $ uname -a
> Linux santana 3.18.3-201.fc21.x86_64 #1 SMP Mon Jan 19 15:59:31 UTC 2015
> x86_64 x86_64 x86_64 GNU/Linux
>
> Ran the following:
>
> sudo strace ./syst_smpl -e instructions:period=1000000 -G
> machine.slice/machine-qemu\\x2drawhide\\x2dx86_64.scope >& strace.out
>
> Looking through the strace.out for the problem run, I foundfirst
> perf_event_open fails with a ENOENT for syst_smpl.
>
> perf_event_open(0x1028d50, 3, 7, -1, PERF_FLAG_PID_CGROUP) = -1 ENOENT (No
> such file or directory)
>
> For the working syst_count see a perf_event_open for each of the processors
> on the machine:
>
> perf_event_open(0x18e0da0, 3, 0, -1, PERF_FLAG_PID_CGROUP) = 4
> perf_event_open(0x18e0fb0, 3, 1, -1, PERF_FLAG_PID_CGROUP) = 5
> perf_event_open(0x18e12b0, 3, 2, -1, PERF_FLAG_PID_CGROUP) = 6
> perf_event_open(0x18e15b0, 3, 3, -1, PERF_FLAG_PID_CGROUP) = 7
> perf_event_open(0x18e18b0, 3, 4, -1, PERF_FLAG_PID_CGROUP) = 8
> perf_event_open(0x18e1bb0, 3, 5, -1, PERF_FLAG_PID_CGROUP) = 9
> perf_event_open(0x18e1eb0, 3, 6, -1, PERF_FLAG_PID_CGROUP) = 10
> perf_event_open(0x18e21b0, 3, 7, -1, PERF_FLAG_PID_CGROUP) = 11
>
> I used gdb and set up a breakpoint in perf_event_open for each of the
> programs.
> On the working perf_event_open of sys_count has the following hw_event_uptr:
>
> (gdb) print *hw_event_uptr
> $1 = {type = 0, size = 96, config = 1, {sample_period = 1000000,
> sample_freq = 1000000}, sample_type = 0, read_format = 3, disabled = 1,
> inherit = 0, pinned = 0, exclusive = 0, exclude_user = 0,
> exclude_kernel = 0, exclude_hv = 0, exclude_idle = 0, mmap = 0, comm = 0,
> freq = 0, inherit_stat = 0, enable_on_exec = 0, task = 0, watermark = 0,
> precise_ip = 0, mmap_data = 0, sample_id_all = 0, exclude_host = 0,
> exclude_guest = 1, exclude_callchain_kernel = 0, exclude_callchain_user = 0,
> __reserved_1 = 0, {wakeup_events = 0, wakeup_watermark = 0}, bp_type = 0, {
> bp_addr = 0, config1 = 0}, {bp_len = 0, config2 = 0},
> branch_sample_type = 0, sample_regs_user = 0, sample_stack_user = 0,
> __reserved_2 = 0}
>
> For the problem syst_smpl the perf_event_open has the following hw_event_uptr:
>
> (gdb) print *hw_event_uptr
> $1 = {type = 0, size = 96, config = 1, {sample_period = 1000000,
> sample_freq = 1000000}, sample_type = 919, read_format = 3, disabled = 1,
> inherit = 0, pinned = 0, exclusive = 0, exclude_user = 0,
> exclude_kernel = 0, exclude_hv = 0, exclude_idle = 0, mmap = 0, comm = 0,
> freq = 0, inherit_stat = 0, enable_on_exec = 0, task = 0, watermark = 1,
> precise_ip = 0, mmap_data = 0, sample_id_all = 0, exclude_host = 0,
> exclude_guest = 1, exclude_callchain_kernel = 0, exclude_callchain_user = 0,
> __reserved_1 = 0, {wakeup_events = 2048, wakeup_watermark = 2048},
> bp_type = 0, {bp_addr = 0, config1 = 0}, {bp_len = 0, config2 = 0},
> branch_sample_type = 0, sample_regs_user = 0, sample_stack_user = 0,
> __reserved_2 = 0}
>
> There is something in thos difference of the hw_event_uptr that is causing
> the issue. The hw_event_uptr->sample_type is 0x397. Is there something in
> PERF_SAMPLE_* that doesn't agree with selecting the group?
>
> For reference here is the hw_event_uptr for syst_smpl being run without the
> "-G machine.slice/machine-qemu\\x2drawhide\\x2dx86_64.scope"
>
> (gdb) print *hw_event_uptr
> $3 = {type = 0, size = 96, config = 1, {sample_period = 1000000,
> sample_freq = 1000000}, sample_type = 919, read_format = 3, disabled = 1,
> inherit = 0, pinned = 0, exclusive = 0, exclude_user = 0,
> exclude_kernel = 0, exclude_hv = 0, exclude_idle = 0, mmap = 0, comm = 0,
> freq = 0, inherit_stat = 0, enable_on_exec = 0, task = 0, watermark = 1,
> precise_ip = 0, mmap_data = 0, sample_id_all = 0, exclude_host = 0,
> exclude_guest = 1, exclude_callchain_kernel = 0, exclude_callchain_user = 0,
> __reserved_1 = 0, {wakeup_events = 2048, wakeup_watermark = 2048},
> bp_type = 0, {bp_addr = 0, config1 = 0}, {bp_len = 0, config2 = 0},
> branch_sample_type = 0, sample_regs_user = 0, sample_stack_user = 0,
> __reserved_2 = 0}
>
> -Will
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
