1. 04 1月, 2011 1 次提交
    • A
      perf test: Add test for counting open syscalls · d854861c
      Arnaldo Carvalho de Melo 提交于
      To test the use of the perf_evsel class on something other than
      the tools from where we refactored code to create it.
      
      It calls open() N times and then checks if the event created to
      monitor it returns N events.
      
      [acme@felicio linux]$ perf test
       1: vmlinux symtab matches kallsyms: Ok
       2: detect open syscall event: Ok
      [acme@felicio linux]$
      
      It does.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Han Pingtian <phan@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d854861c
  2. 23 12月, 2010 1 次提交
    • A
      perf test: Look forward for symbol aliases · d3678758
      Arnaldo Carvalho de Melo 提交于
      Not just before, fixing these false positives:
      
      [acme@mica linux]$ perf test -v 1
       1: vmlinux symtab matches kallsyms:
      --- start ---
      Looking at the vmlinux_path (6 entries long)
      Using //lib/modules/2.6.37-rc5-00180-ge06b6bf/build/vmlinux for symbols
      0xffffffff81058dc0: diff name v: sys_vm86old k: sys_ni_syscall
      0xffffffff81058dc0: diff name v: sys_vm86 k: sys_ni_syscall
      0xffffffff81058dc0: diff name v: sys_subpage_prot k: sys_ni_syscall
      0xffffffff810b5f7c: diff name v: probe_kernel_write k: __probe_kernel_write
      0xffffffff810b5fe5: diff name v: probe_kernel_read k: __probe_kernel_read
      0xffffffff811bc380: diff name v: __memset k: memset
      0xffffffff81384a98: diff name v: __sched_text_start k: sleep_on_common
      0xffffffff81386750: diff name v: __sched_text_end k: _raw_spin_trylock
      0xffffffff8138cee8: diff name v: __irqentry_text_start k: do_IRQ
      0xffffffff8138f079: diff name v: __start_notes k: _etext
      0xffffffff8138f079: diff name v: __stop_notes k: _etext
      ---- end ----
      vmlinux symtab matches kallsyms: FAILED!
      
      [acme@mica linux]$
      
      Some are weak functions, others are just markers, etc. They get in the rb tree
      with the same addr, so we need to look around to find the symbol with the same
      name.
      
      We were looking just at the previous entries with the same addr, look forward
      too.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Han Pingtian <phan@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Stephane Eranian <eranian@google.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d3678758
  3. 18 5月, 2010 1 次提交
  4. 30 4月, 2010 1 次提交
    • A
      perf test: Initial regression testing command · 1c6a800c
      Arnaldo Carvalho de Melo 提交于
      First an example with the first internal test:
      
      [acme@doppio linux-2.6-tip]$ perf test
       1: vmlinux symtab matches kallsyms: Ok
      
      So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
      successful.
      
      If we run it in verbose mode, we'll see details about errors and extra warnings
      for non-fatal problems:
      
      [acme@doppio linux-2.6-tip]$ perf test -v
       1: vmlinux symtab matches kallsyms:
      --- start ---
      Looking at the vmlinux_path (5 entries long)
      No build_id in vmlinux, ignoring it
      No build_id in /boot/vmlinux, ignoring it
      No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
      Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
      Maps only in vmlinux:
       ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
       ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
       ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
       ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
       ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
       ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
      Maps in vmlinux with a different name in kallsyms:
       ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
       ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
      *ffffffffff600100-ffffffffff60012f 0 [kernel].2
       ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
       ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
      Maps only in kallsyms:
       ffffffffff600130-ffffffffff6003ff 0 [kernel].4
      ---- end ----
      vmlinux symtab matches kallsyms: Ok
      [acme@doppio linux-2.6-tip]$
      
      In the above case we only know the name of the non contiguous kernel ranges in
      the address space when reading the symbol information from the ELF symtab in
      vmlinux.
      
      The /proc/kallsyms file lack this, we only notice they are separate because
      there are modules after the kernel and after that more kernel functions, so we
      need to have a module rbtree backed by the module .ko path to get symtabs in
      the vmlinux case.
      
      The tool uses it to match by address to emit appropriate warning, but don't
      considers this fatal.
      
      The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
      these cases just as extra info in verbose mode.
      
      The end of the sections also aren't in kallsyms, so we the symbols layer does
      another pass and sets the end addresses as the next map start minus one, which
      sometimes pads, causing harmless mismatches.
      
      But at least the symbols match, tested it by copying /proc/kallsyms to
      /tmp/kallsyms and doing changes to see if they were detected.
      
      This first test also should serve as a first stab at documenting the
      symbol library by providing a self contained example that exercises it
      together with comments about what is being done.
      
      More tests to check if actions done on a monitored app, like doing mmaps, etc,
      makes the kernel generate the expected events should be added next.
      
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1c6a800c