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

Reply via email to