1. 29 Apr, 2015 34 commits
  2. 14 Apr, 2015 1 commit
  3. 13 Apr, 2015 5 commits
    • He Kuang's avatar
      perf probe: Fix segfault when probe with lazy_line to file · f19e80c6
      He Kuang authored
      The first argument passed to find_probe_point_lazy() should be CU die,
      which will be passed to die_walk_lines() when lazy_line matches.
      Currently, when we probe with lazy_line pattern to file without function
      name, NULL pointer is passed and causes a segment fault.
      
      Can be reproduced as following:
      
        $ perf probe -k vmlinux --add='fs/super.c;s->s_count=1;'
        [ 1958.984658] perf[1020]: segfault at 10 ip 00007fc6e10d8c71 sp
        00007ffcbfaaf900 error 4 in libdw-0.161.so[7fc6e10ce000+34000]
        Segmentation fault
      
      After this patch:
      
        $ perf probe -k vmlinux --add='fs/super.c;s->s_count=1;'
        Added new event:
        probe:_stext         (on @fs/super.c)
      
        You can now use it in all perf tools, such as:
          perf record -e probe:_stext -aR sleep 1
      Signed-off-by: default avatarHe Kuang <hekuang@huawei.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1428925290-5623-3-git-send-email-hekuang@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      f19e80c6
    • Naohiro Aota's avatar
      perf probe: Find compilation directory path for lazy matching · 09ed8975
      Naohiro Aota authored
      If we use lazy matching, it failed to open a souce file if perf command
      is invoked outside of compilation directory:
      
      $ perf probe -a '__schedule;clear_*'
      Failed to open kernel/sched/core.c: No such file or directory
        Error: Failed to add events. (-2)
      
      OTOH, other commands like "probe -L" can solve the souce directory by
      themselves. Let's make it possible for lazy matching too!
      Signed-off-by: default avatarNaohiro Aota <naota@elisp.net>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1426223923-1493-1-git-send-email-naota@elisp.netSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      09ed8975
    • He Kuang's avatar
      perf probe: Set retprobe flag when probe in address-based alternative mode · 9d7b45c5
      He Kuang authored
      When perf probe searched in a debuginfo file and failed, it tried with
      an alternative, in function get_alternative_probe_event():
      
              memcpy(tmp, &pev->point, sizeof(*tmp));
              memset(&pev->point, 0, sizeof(pev->point));
      
      In this case, it drops the retprobe flag and forgets to set it back in
      find_alternative_probe_point(), so the problem occurs.
      
      Can be reproduced as following:
      
        $ perf probe -v -k vmlinux --add='sys_write%return'
        ...
        Added new event:
        Writing event: p:probe/sys_write _stext+1584952
          probe:sys_write      (on sys_write%return)
      
        $ cat /sys/kernel/debug/tracing/kprobe_events
        p:probe/sys_write _stext+1584952
      
      After this patch:
      
        $ perf probe -v -k vmlinux --add='sys_write%return'
        Added new event:
        Writing event: r:probe/sys_write SyS_write+0
          probe:sys_write      (on sys_write%return)
      
        $ cat /sys/kernel/debug/tracing/kprobe_events
        r:probe/sys_write SyS_write
      Signed-off-by: default avatarHe Kuang <hekuang@huawei.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1428925290-5623-1-git-send-email-hekuang@huawei.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      9d7b45c5
    • Namhyung Kim's avatar
      perf kmem: Analyze page allocator events also · 0d68bc92
      Namhyung Kim authored
      The perf kmem command records and analyze kernel memory allocation only
      for SLAB objects.  This patch implement a simple page allocator analyzer
      using kmem:mm_page_alloc and kmem:mm_page_free events.
      
      It adds two new options of --slab and --page.  The --slab option is for
      analyzing SLAB allocator and that's what perf kmem currently does.
      
      The new --page option enables page allocator events and analyze kernel
      memory usage in page unit.  Currently, 'stat --alloc' subcommand is
      implemented only.
      
      If none of these --slab nor --page is specified, --slab is implied.
      
      First run 'perf kmem record' to generate a suitable perf.data file:
      
        # perf kmem record --page sleep 5
      
      Then run 'perf kmem stat' to postprocess the perf.data file:
      
        # perf kmem stat --page --alloc --line 10
      
        -------------------------------------------------------------------------------
         PFN              | Total alloc (KB) | Hits     | Order | Mig.type | GFP flags
        -------------------------------------------------------------------------------
                  4045014 |               16 |        1 |     2 |  RECLAIM |  00285250
                  4143980 |               16 |        1 |     2 |  RECLAIM |  00285250
                  3938658 |               16 |        1 |     2 |  RECLAIM |  00285250
                  4045400 |               16 |        1 |     2 |  RECLAIM |  00285250
                  3568708 |               16 |        1 |     2 |  RECLAIM |  00285250
                  3729824 |               16 |        1 |     2 |  RECLAIM |  00285250
                  3657210 |               16 |        1 |     2 |  RECLAIM |  00285250
                  4120750 |               16 |        1 |     2 |  RECLAIM |  00285250
                  3678850 |               16 |        1 |     2 |  RECLAIM |  00285250
                  3693874 |               16 |        1 |     2 |  RECLAIM |  00285250
         ...              | ...              | ...      | ...   | ...      | ...
        -------------------------------------------------------------------------------
      
        SUMMARY (page allocator)
        ========================
        Total allocation requests     :           44,260   [          177,256 KB ]
        Total free requests           :              117   [              468 KB ]
      
        Total alloc+freed requests    :               49   [              196 KB ]
        Total alloc-only requests     :           44,211   [          177,060 KB ]
        Total free-only requests      :               68   [              272 KB ]
      
        Total allocation failures     :                0   [                0 KB ]
      
        Order     Unmovable   Reclaimable       Movable      Reserved  CMA/Isolated
        -----  ------------  ------------  ------------  ------------  ------------
            0            32             .        44,210             .             .
            1             .             .             .             .             .
            2             .            18             .             .             .
            3             .             .             .             .             .
            4             .             .             .             .             .
            5             .             .             .             .             .
            6             .             .             .             .             .
            7             .             .             .             .             .
            8             .             .             .             .             .
            9             .             .             .             .             .
           10             .             .             .             .             .
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Joonsoo Kim <js1304@gmail.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/1428298576-9785-4-git-send-email-namhyung@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      0d68bc92
    • Namhyung Kim's avatar
      tracing, mm: Record pfn instead of pointer to struct page · 9fdd8a87
      Namhyung Kim authored
      The struct page is opaque for userspace tools, so it'd be better to save
      pfn in order to identify page frames.
      
      The textual output of $debugfs/tracing/trace file remains unchanged and
      only raw (binary) data format is changed - but thanks to libtraceevent,
      userspace tools which deal with the raw data (like perf and trace-cmd)
      can parse the format easily.  So impact on the userspace will also be
      minimal.
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Based-on-patch-by: default avatarJoonsoo Kim <js1304@gmail.com>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/1428298576-9785-3-git-send-email-namhyung@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      9fdd8a87