1. 29 5月, 2019 2 次提交
    • A
      perf trace: Beautify 'fspick' arguments · 693bd394
      Arnaldo Carvalho de Melo 提交于
      Use existing beautifiers for the first 2 args (dfd, path) and wire up
      the recently introduced fspick flags table generator.
      
      Now it should be possible to just use:
      
         perf trace -e fspick
      
      As root and see all move_mount syscalls with its args beautified, either
      using the vfs_getname perf probe method or using the
      augmented_raw_syscalls.c eBPF helper to get the pathnames, the other
      args should work in all cases, i.e. all that is needed can be obtained
      directly from the raw_syscalls:sys_enter tracepoint args.
      
        # cat sys_fspick.c
        #define _GNU_SOURCE        /* See feature_test_macros(7) */
        #include <unistd.h>
        #include <sys/syscall.h>   /* For SYS_xxx definitions */
        #include <fcntl.h>
      
        #define __NR_fspick 433
      
        #define FSPICK_CLOEXEC          0x00000001
        #define FSPICK_SYMLINK_NOFOLLOW 0x00000002
        #define FSPICK_NO_AUTOMOUNT     0x00000004
        #define FSPICK_EMPTY_PATH       0x00000008
      
        static inline int sys_fspick(int fd, const char *path, int flags)
        {
        	syscall(__NR_fspick, fd, path, flags);
        }
      
        int main(int argc, char *argv[])
        {
        	int flags = 0, fd = 0;
      
        	open("/foo", 0);
        	sys_fspick(fd++, "/foo1", flags);
        	flags |= FSPICK_CLOEXEC;
        	sys_fspick(fd++, "/foo2", flags);
        	flags |= FSPICK_SYMLINK_NOFOLLOW;
        	sys_fspick(fd++, "/foo3", flags);
        	flags |= FSPICK_NO_AUTOMOUNT;
        	sys_fspick(fd++, "/foo4", flags);
        	flags |= FSPICK_EMPTY_PATH;
        	return sys_fspick(fd++, "/foo5", flags);
        }
        # perf trace -e fspick ./sys_fspick
        LLVM: dumping /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o
        fspick(0, "/foo1", 0)                   = -1 ENOENT (No such file or directory)
        fspick(1, "/foo2", FSPICK_CLOEXEC)      = -1 ENOENT (No such file or directory)
        fspick(2, "/foo3", FSPICK_CLOEXEC|FSPICK_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory)
        fspick(3, "/foo4", FSPICK_CLOEXEC|FSPICK_SYMLINK_NOFOLLOW|FSPICK_NO_AUTOMOUNT) = -1 ENOENT (No such file or directory)
        fspick(4, "/foo5", FSPICK_CLOEXEC|FSPICK_SYMLINK_NOFOLLOW|FSPICK_NO_AUTOMOUNT|FSPICK_EMPTY_PATH) = -1 ENOENT (No such file or directory)
        #
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Luis Cláudio Gonçalves <lclaudio@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: https://lkml.kernel.org/n/tip-erau5xjtt8wvgnhvdbchstuk@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      693bd394
    • A
      perf trace: Beautify 'move_mount' arguments · 566e3022
      Arnaldo Carvalho de Melo 提交于
      Use existing beautifiers for the first 4 args (to/from fds, pathnames)
      and wire up the recently introduced move_mount flags table generator.
      
      Now it should be possible to just use:
      
            perf trace -e move_mount
      
      As root and see all move_mount syscalls with its args beautified, except
      for the filenames, that need work in the augmented_raw_syscalls.c eBPF
      helper to pass more than one, see comment in the
      augmented_raw_syscalls.c source code, the other args should work in all
      cases, i.e. all that is needed can be obtained directly from the
      raw_syscalls:sys_enter tracepoint args.
      
      Running without the strace "skin" (.perfconfig setting output formatting
      switches to look like strace output + BPF to collect strings, as we
      still need to support collecting multiple string args for the same
      syscall, like with move_mount):
      
        # cat sys_move_mount.c
        #define _GNU_SOURCE         /* See feature_test_macros(7) */
        #include <unistd.h>
        #include <sys/syscall.h>   /* For SYS_xxx definitions */
      
        #define __NR_move_mount 429
      
        #define MOVE_MOUNT_F_SYMLINKS		0x00000001 /* Follow symlinks on from path */
        #define MOVE_MOUNT_F_AUTOMOUNTS		0x00000002 /* Follow automounts on from path */
        #define MOVE_MOUNT_F_EMPTY_PATH		0x00000004 /* Empty from path permitted */
        #define MOVE_MOUNT_T_SYMLINKS		0x00000010 /* Follow symlinks on to path */
        #define MOVE_MOUNT_T_AUTOMOUNTS		0x00000020 /* Follow automounts on to path */
        #define MOVE_MOUNT_T_EMPTY_PATH		0x00000040 /* Empty to path permitted */
      
        static inline int sys_move_mount(int from_fd, const char *from_pathname,
        				 int to_fd, const char *to_pathname,
        				 int flags)
        {
        	  syscall(__NR_move_mount, from_fd, from_pathname, to_fd, to_pathname, flags);
        }
      
        int main(int argc, char *argv[])
        {
        	  int flags = 0, from_fd = 0, to_fd = 100;
      
        	  sys_move_mount(from_fd++, "/foo", to_fd++, "bar", flags);
        	  flags |= MOVE_MOUNT_F_SYMLINKS;
        	  sys_move_mount(from_fd++, "/foo1", to_fd++, "bar1", flags);
                flags |= MOVE_MOUNT_F_AUTOMOUNTS;
        	  sys_move_mount(from_fd++, "/foo2", to_fd++, "bar2", flags);
                flags |= MOVE_MOUNT_F_EMPTY_PATH;
        	  sys_move_mount(from_fd++, "/foo3", to_fd++, "bar3", flags);
                flags |= MOVE_MOUNT_T_SYMLINKS;
        	  sys_move_mount(from_fd++, "/foo4", to_fd++, "bar4", flags);
                flags |= MOVE_MOUNT_T_AUTOMOUNTS;
        	  sys_move_mount(from_fd++, "/foo5", to_fd++, "bar5", flags);
                flags |= MOVE_MOUNT_T_EMPTY_PATH;
        	  return sys_move_mount(from_fd++, "/foo6", to_fd++, "bar6", flags);
        }
        # mv ~/.perfconfig  ~/.perfconfig.OFF
        # perf trace -e move_mount ./sys_move_mount
             0.000 ( 0.009 ms): sys_move_mount/28971 move_mount(from_pathname: 0x402010, to_dfd: 100, to_pathname: 0x402015) = -1 ENOENT (No such file or directory)
             0.011 ( 0.003 ms): sys_move_mount/28971 move_mount(from_dfd: 1, from_pathname: 0x40201e, to_dfd: 101, to_pathname: 0x402019, flags: F_SYMLINKS) = -1 ENOENT (No such file or directory)
             0.016 ( 0.002 ms): sys_move_mount/28971 move_mount(from_dfd: 2, from_pathname: 0x402029, to_dfd: 102, to_pathname: 0x402024, flags: F_SYMLINKS|F_AUTOMOUNTS) = -1 ENOENT (No such file or directory)
             0.020 ( 0.002 ms): sys_move_mount/28971 move_mount(from_dfd: 3, from_pathname: 0x402034, to_dfd: 103, to_pathname: 0x40202f, flags: F_SYMLINKS|F_AUTOMOUNTS|F_EMPTY_PATH) = -1 ENOENT (No such file or directory)
             0.023 ( 0.002 ms): sys_move_mount/28971 move_mount(from_dfd: 4, from_pathname: 0x40203f, to_dfd: 104, to_pathname: 0x40203a, flags: F_SYMLINKS|F_AUTOMOUNTS|F_EMPTY_PATH|T_SYMLINKS) = -1 ENOENT (No such file or directory)
             0.027 ( 0.002 ms): sys_move_mount/28971 move_mount(from_dfd: 5, from_pathname: 0x40204a, to_dfd: 105, to_pathname: 0x402045, flags: F_SYMLINKS|F_AUTOMOUNTS|F_EMPTY_PATH|T_SYMLINKS|T_AUTOMOUNTS) = -1 ENOENT (No such file or directory)
             0.031 ( 0.017 ms): sys_move_mount/28971 move_mount(from_dfd: 6, from_pathname: 0x402055, to_dfd: 106, to_pathname: 0x402050, flags: F_SYMLINKS|F_AUTOMOUNTS|F_EMPTY_PATH|T_SYMLINKS|T_AUTOMOUNTS|T_EMPTY_PATH) = -1 ENOENT (No such file or directory)
        #
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: https://lkml.kernel.org/n/tip-83rim8g4k0s4gieieh5nnlck@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      566e3022
  2. 02 4月, 2019 1 次提交
  3. 29 3月, 2019 1 次提交
    • A
      tools headers uapi: Sync asm-generic/mman-common.h and linux/mman.h · be709d48
      Arnaldo Carvalho de Melo 提交于
      To deal with the move of some defines from asm-generic/mmap-common.h to
      linux/mman.h done in:
      
        746c9398 ("arch: move common mmap flags to linux/mman.h")
      
      The generated mmap_flags array stays the same:
      
        $ tools/perf/trace/beauty/mmap_flags.sh
        static const char *mmap_flags[] = {
      	[ilog2(0x40) + 1] = "32BIT",
      	[ilog2(0x01) + 1] = "SHARED",
      	[ilog2(0x02) + 1] = "PRIVATE",
      	[ilog2(0x10) + 1] = "FIXED",
      	[ilog2(0x20) + 1] = "ANONYMOUS",
      	[ilog2(0x100000) + 1] = "FIXED_NOREPLACE",
      	[ilog2(0x0100) + 1] = "GROWSDOWN",
      	[ilog2(0x0800) + 1] = "DENYWRITE",
      	[ilog2(0x1000) + 1] = "EXECUTABLE",
      	[ilog2(0x2000) + 1] = "LOCKED",
      	[ilog2(0x4000) + 1] = "NORESERVE",
      	[ilog2(0x8000) + 1] = "POPULATE",
      	[ilog2(0x10000) + 1] = "NONBLOCK",
      	[ilog2(0x20000) + 1] = "STACK",
      	[ilog2(0x40000) + 1] = "HUGETLB",
      	[ilog2(0x80000) + 1] = "SYNC",
        };
        $
      
      And to have the system's sys/mman.h find the definition of MAP_SHARED
      and MAP_PRIVATE, make sure they are defined in the tools/ mman-common.h
      in a way that keeps it the same as the kernel's, need for keeping the
      Android's NDK cross build working.
      
      This silences these perf build warnings:
      
        Warning: Kernel ABI header at 'tools/include/uapi/asm-generic/mman-common.h' differs from latest version at 'include/uapi/asm-generic/mman-common.h'
        diff -u tools/include/uapi/asm-generic/mman-common.h include/uapi/asm-generic/mman-common.h
        Warning: Kernel ABI header at 'tools/include/uapi/linux/mman.h' differs from latest version at 'include/uapi/linux/mman.h'
        diff -u tools/include/uapi/linux/mman.h include/uapi/linux/mman.h
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: https://lkml.kernel.org/n/tip-h80ycpc6pedg9s5z2rwpy6ws@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      be709d48
  4. 15 2月, 2019 3 次提交
    • J
      perf tools: Rename LIB_FILE to LIBPERF_A · 6368942a
      Jiri Olsa 提交于
      Simple rename, no functional change.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20190213123246.4015-3-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6368942a
    • J
      perf tools: Compile perf with libperf-in.o instead of libperf.a · d0bfbeda
      Jiri Olsa 提交于
      There's no need for perf build to use libperf.a,
      we can use directly libperf-in.o.
      
      The libperf.a stays as a target if needed:
      
        $ make libperf.a
        ...
          CC       util/pmu.o
          CC       util/pmu-flex.o
          LD       util/libperf-in.o
          LD       libperf-in.o
          AR       libperf.a
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20190213123246.4015-2-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d0bfbeda
    • A
      perf coresight: Do not test for libopencsd by default · 1c3b28fd
      Arnaldo Carvalho de Melo 提交于
      Since it is not yet that generally available, avoid testing for the
      presence of libcoresight in the fast path test-all.bin feature test.
      
        # dnf search opencsd
        No matches found.
        # dnf search OpenCSD
        No matches found.
        # cat /etc/fedora-release
        Fedora release 29 (Twenty Nine)
        #
      
      I.e. right now, in my system test-all.bin is failing all the time since
      Fedora29 doesn't have libopencsd available:
      
        $ cat /tmp/build/perf/feature/test-all.make.output
        In file included from test-all.c:174:
        test-libopencsd.c:2:10: fatal error: opencsd/c_api/opencsd_c_api.h: No such file or directory
         #include <opencsd/c_api/opencsd_c_api.h>
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        compilation terminated.
      
      See:
      
        6ab2b762 ("perf build: Disable libbabeltrace check by default")
      
      For the rationale, as soon as libopencsd becomes more generally packaged
      and available, we do the same thing we did with babeltrace, enabling it
      by default, as done in:
      
        24787afb ("perf tools: Enable LIBBABELTRACE by default")
      
      For now, to explicitely ask for opencsd, make sure you have it installed
      and use:
      
         make -C tools/perf CORESIGHT=1
      
      The feature test output will be there as an empty file:
      
        $ ls -la /tmp/build/perf/feature/test-libopencsd.make.output
      
      Because the binary used for the feature check was successfully built:
      
        $ ls -la /tmp/build/perf/feature/test-libopencsd.bin
        -rwxrwxr-x. 1 acme acme 18336 Feb 12 14:49 /tmp/build/perf/feature/test-libopencsd.bin
        $ ldd /tmp/build/perf/feature/test-libopencsd.bin
      	linux-vdso.so.1 (0x00007fffe18cc000)
      	libopencsd_c_api.so.0 => /lib64/libopencsd_c_api.so.0 (0x00007fb8e67f6000)
      	libopencsd.so.0 => /lib64/libopencsd.so.0 (0x00007fb8e676f000)
      	libc.so.6 => /lib64/libc.so.6 (0x00007fb8e65a9000)
      	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb8e6411000)
      	libm.so.6 => /lib64/libm.so.6 (0x00007fb8e628d000)
      	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb8e6272000)
      	/lib64/ld-linux-x86-64.so.2 (0x00007fb8e6828000)
        $
      
      And the resulting perf binary will be linked with it:
      
        -rw-rw-r--. 1 acme acme 0 Feb 12 14:49 /tmp/build/perf/feature/test-libopencsd.make.output
        $ ldd ~/bin/perf | grep opencsd
      	libopencsd_c_api.so.0 => /lib64/libopencsd_c_api.so.0 (0x00007fd43097f000)
      	libopencsd.so.0 => /lib64/libopencsd.so.0 (0x00007fd4308f8000)
        $
      
      To make sure this gets built before pushing things upstream I have a
      ubuntu:19.04-x-arm64 container that has:
      
        [root@quaco x-arm64]# grep CORESIGHT Dockerfile
        ENV EXTRA_MAKE_ARGS=CORESIGHT=1
        [root@quaco x-arm64]#
      
      So that I always build with libopencsd before pushing things upstream.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Mike Leach <mike.leach@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Link: https://lkml.kernel.org/n/tip-20vyy39jw9jgrijesi30fgox@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1c3b28fd
  5. 25 1月, 2019 1 次提交
  6. 09 1月, 2019 1 次提交
  7. 04 1月, 2019 1 次提交
  8. 29 12月, 2018 1 次提交
    • A
      perf trace: Wire up ioctl's USBDEBFS_ cmd table generator · 86cf4c65
      Arnaldo Carvalho de Melo 提交于
      That ends up generating this:
      
        [acme@quaco perf]$ cat /tmp/build/perf/trace/beauty/generated/ioctl/usbdevfs_ioctl_array.c
        static const char *usbdevfs_ioctl_cmds[] = {
      	[0] = "CONTROL",
      	[10] = "SUBMITURB",
      	[11] = "DISCARDURB",
      	[12] = "REAPURB",
      	[13] = "REAPURBNDELAY",
      	[14] = "DISCSIGNAL",
      	[15] = "CLAIMINTERFACE",
      	[16] = "RELEASEINTERFACE",
      	[17] = "CONNECTINFO",
      	[18] = "IOCTL",
      	[19] = "HUB_PORTINFO",
      	[2] = "BULK",
      	[20] = "RESET",
      	[21] = "CLEAR_HALT",
      	[22] = "DISCONNECT",
      	[23] = "CONNECT",
      	[24] = "CLAIM_PORT",
      	[25] = "RELEASE_PORT",
      	[26] = "GET_CAPABILITIES",
      	[27] = "DISCONNECT_CLAIM",
      	[28] = "ALLOC_STREAMS",
      	[29] = "FREE_STREAMS",
      	[3] = "RESETEP",
      	[30] = "DROP_PRIVILEGES",
      	[31] = "GET_SPEED",
      	[4] = "SETINTERFACE",
      	[5] = "SETCONFIGURATION",
      	[8] = "GETDRIVER",
        };
      
        #if 0
        static const char *usbdevfs_ioctl_32_cmds[] = {
      	[0] = "CONTROL32",
      	[10] = "SUBMITURB32",
      	[12] = "REAPURB32",
      	[13] = "REAPURBNDELAY32",
      	[14] = "DISCSIGNAL32",
      	[18] = "IOCTL32",
      	[2] = "BULK32",
        };
        #endif
        $
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Luis Cláudio Gonçalves <lclaudio@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-hkam6lt1g806l0p4b7buif3n@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      86cf4c65
  9. 19 12月, 2018 2 次提交
  10. 18 12月, 2018 4 次提交
  11. 22 11月, 2018 1 次提交
    • J
      perf jvmti: Separate jvmti cmlr check · dd1d0044
      Jiri Olsa 提交于
      The Compiled Method Load Record (cmlr) is JDK specific interface to
      access JVM stack info. This makes the jvmti agent code not compile under
      another jdk, which does not support that.
      
      Separating jvmti cmlr check into special feature check, and adding
      HAVE_JVMTI_CMLR macro to indicate that.
      
      Mark cmlr code in jvmti/libjvmti.c with HAVE_JVMTI_CMLR, so we can
      compile it on system without cmlr support.
      
      This change makes the jvmti compile with java-1.8.0-ibm package. It's
      without the line numbers support, but the rest works.
      
      Adding NO_JVMTI_CMLR compile variable for testing.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ben Gainey <ben.gainey@arm.com>
      Cc: Gustavo Luiz Duarte <gduarte@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/20181121154341.21521-1-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      dd1d0044
  12. 06 11月, 2018 1 次提交
    • A
      perf beauty: Use SRCARCH, ARCH=x86_64 must map to "x86" to find the headers · e2c39f36
      Arnaldo Carvalho de Melo 提交于
      Guenter reported that using ARCH=x86_64 to build perf has regressed:
      
        $ make -C tools/perf O=/tmp/build/perf ARCH=x86_64
        make: Entering directory '/home/acme/git/perf/tools/perf'
          BUILD:   Doing 'make -j4' parallel build
          HOSTCC   /tmp/build/perf/fixdep.o
          HOSTLD   /tmp/build/perf/fixdep-in.o
          LINK     /tmp/build/perf/fixdep
      
        Auto-detecting system features:
        ...                         dwarf: [ on  ]
        <SNIP>
        ...                           bpf: [ on  ]
      
          GEN      /tmp/build/perf/common-cmds.h
        make[2]: *** No rule to make target '/home/acme/git/perf/tools/arch/x86_64/include/uapi/asm//mman.h', needed by '/tmp/build/perf/trace/beauty/generated/mmap_flags_array.c'.  Stop.
        make[2]: *** Waiting for unfinished jobs....
          PERF_VERSION = 4.19.gf6c23e3b
        make[1]: *** [Makefile.perf:207: sub-make] Error 2
        make: *** [Makefile:70: all] Error 2
        make: Leaving directory '/home/acme/git/perf/tools/perf'
        $
      
      This is because we must use $(SRCARCH) where we were using $(ARCH), so
      that, just like the top level Makefile, we get this done:
      
        # Additional ARCH settings for x86
        ifeq ($(ARCH),i386)
                SRCARCH := x86
        endif
        ifeq ($(ARCH),x86_64)
                SRCARCH := x86
        endif
      
      Which is done in tools/scripts/Makefile.arch, so switch to use
      $(SRCARCH).
      Reported-by: NGuenter Roeck <linux@roeck-us.net>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Clark Williams <williams@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Fixes: fbd7458d ("perf beauty: Wire up the mmap flags table generator to the Makefile")
      Link: https://lkml.kernel.org/r/20181105184612.GD7077@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e2c39f36
  13. 31 10月, 2018 1 次提交
    • A
      perf beauty: Wire up the mmap flags table generator to the Makefile · fbd7458d
      Arnaldo Carvalho de Melo 提交于
      Now when we run 'make -C tools/perf O=/tmp/build/perf' we end up with:
      
        $ cat /tmp/build/perf/trace/beauty/generated/mmap_flags_array.c
        static const char *mmap_flags[] = {
      	[ilog2(0x40) + 1] = "32BIT",
      	[ilog2(0x01) + 1] = "SHARED",
      	[ilog2(0x02) + 1] = "PRIVATE",
      	[ilog2(0x10) + 1] = "FIXED",
      	[ilog2(0x20) + 1] = "ANONYMOUS",
      	[ilog2(0x100000) + 1] = "FIXED_NOREPLACE",
      	[ilog2(0x0100) + 1] = "GROWSDOWN",
      	[ilog2(0x0800) + 1] = "DENYWRITE",
      	[ilog2(0x1000) + 1] = "EXECUTABLE",
      	[ilog2(0x2000) + 1] = "LOCKED",
      	[ilog2(0x4000) + 1] = "NORESERVE",
      	[ilog2(0x8000) + 1] = "POPULATE",
      	[ilog2(0x10000) + 1] = "NONBLOCK",
      	[ilog2(0x20000) + 1] = "STACK",
      	[ilog2(0x40000) + 1] = "HUGETLB",
      	[ilog2(0x80000) + 1] = "SYNC",
        };
        $
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-t3fn7u3tjsupio6e6vkufx9m@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fbd7458d
  14. 30 10月, 2018 1 次提交
    • A
      perf trace beauty: Beautify mount/umount's 'flags' argument · 73d141ad
      Arnaldo Carvalho de Melo 提交于
        # trace -e mount mount -o ro -t debugfs nodev /mnt
           0.000 ( 1.040 ms): mount/27235 mount(dev_name: 0x5601cc8c64e0, dir_name: 0x5601cc8c6500, type: 0x5601cc8c6480, flags: RDONLY) = 0
        # trace -e mount mount -o remount,relatime -t debugfs nodev /mnt
           0.000 ( 2.946 ms): mount/27262 mount(dev_name: 0x55f4a73d64e0, dir_name: 0x55f4a73d6500, type: 0x55f4a73d6480, flags: REMOUNT|RELATIME) = 0
        # trace -e mount mount -o remount,strictatime -t debugfs nodev /mnt
           0.000 ( 2.934 ms): mount/27265 mount(dev_name: 0x5617f71d94e0, dir_name: 0x5617f71d9500, type: 0x5617f71d9480, flags: REMOUNT|STRICTATIME) = 0
        # trace -e mount mount -o remount,suid,silent -t debugfs nodev /mnt
           0.000 ( 0.049 ms): mount/27273 mount(dev_name: 0x55ad65df24e0, dir_name: 0x55ad65df2500, type: 0x55ad65df2480, flags: REMOUNT|SILENT) = 0
        # trace -e mount mount -o remount,rw,sync,lazytime -t debugfs nodev /mnt
           0.000 ( 2.684 ms): mount/27281 mount(dev_name: 0x561216055530, dir_name: 0x561216055550, type: 0x561216055510, flags: SYNCHRONOUS|REMOUNT|LAZYTIME) = 0
        # trace -e mount mount -o remount,dirsync -t debugfs nodev /mnt
           0.000 ( 3.512 ms): mount/27314 mount(dev_name: 0x55c4e7188480, dir_name: 0x55c4e7188530, type: 0x55c4e71884a0, flags: REMOUNT|DIRSYNC, data: 0x55c4e71884e0) = 0
        #
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Benjamin Peterson <benjamin@python.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-i5ncao73c0bd02qprgrq6wb9@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      73d141ad
  15. 17 10月, 2018 1 次提交
  16. 31 8月, 2018 2 次提交
  17. 31 7月, 2018 1 次提交
  18. 19 5月, 2018 1 次提交
  19. 16 5月, 2018 3 次提交
    • A
      perf bpf: Add bpf.h to be used in eBPF proggies · dd8e4ead
      Arnaldo Carvalho de Melo 提交于
      So, the first helper is the one shortening a variable/function section
      attribute, from, for instance:
      
        char _license[] __attribute__((section("license"), used)) = "GPL";
      
      to:
      
        char _license[] SEC("license") = "GPL";
      
      Convert empty.c to that and it becomes:
      
        # cat ~acme/lib/examples/perf/bpf/empty.c
        #include <bpf.h>
      
        char _license[] SEC("license") = "GPL";
        int _version SEC("version") = LINUX_VERSION_CODE;
        #
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-zmeg52dlvy51rdlhyumfl5yf@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      dd8e4ead
    • A
      perf bpf: Add 'examples' directories · 8f12a2ff
      Arnaldo Carvalho de Melo 提交于
      The first one is the bare minimum that bpf infrastructure accepts before
      it expects actual events to be set up:
      
        $ cat tools/perf/examples/bpf/empty.c
        char _license[] __attribute__((section("license"), used)) = "GPL";
        int _version __attribute__((section("version"), used)) = LINUX_VERSION_CODE;
        $
      
      If you remove that "version" line, then it will be refused with:
      
        # perf trace -e tools/perf/examples/bpf/empty.c
        event syntax error: 'tools/perf/examples/bpf/empty.c'
                             \___ Failed to load tools/perf/examples/bpf/empty.c from source: 'version' section incorrect or lost
      
        (add -v to see detail)
        Run 'perf list' for a list of valid events
      
         Usage: perf trace [<options>] [<command>]
            or: perf trace [<options>] -- <command> [<options>]
            or: perf trace record [<options>] [<command>]
            or: perf trace record [<options>] -- <command> [<options>]
      
            -e, --event <event>   event/syscall selector. use 'perf list' to list available events
        #
      
      The next ones will, step by step, show simple filters, then the needs
      for headers will be made clear, it will be put in place and tested with
      new examples, rinse, repeat.
      
      Back to using this first one to test the perf+bpf infrastructure:
      
      If we run it will fail, as no functions are present connecting with,
      say, a tracepoint or a function using the kprobes or uprobes
      infrastructure:
      
        # perf trace -e tools/perf/examples/bpf/empty.c
        WARNING: event parser found nothing
        invalid or unsupported event: 'tools/perf/examples/bpf/empty.c'
        Run 'perf list' for a list of valid events
      
         Usage: perf trace [<options>] [<command>]
            or: perf trace [<options>] -- <command> [<options>]
            or: perf trace record [<options>] [<command>]
            or: perf trace record [<options>] -- <command> [<options>]
      
            -e, --event <event>   event/syscall selector. use 'perf list' to list available events
        #
      
      But, if we set things up to dump the generated object file to a file,
      and do this after having run 'make install', still on the developer's
      $HOME directory:
      
        # cat ~/.perfconfig
        [llvm]
      
      	dump-obj = true
        #
        # perf trace -e ~acme/lib/examples/perf/bpf/empty.c
        LLVM: dumping /home/acme/lib/examples/perf/bpf/empty.o
        WARNING: event parser found nothing
        invalid or unsupported event: '/home/acme/lib/examples/perf/bpf/empty.c'
        <SNIP>
        #
      
      We can look at the dumped object file:
      
        # ls -la ~acme/lib/examples/perf/bpf/empty.o
        -rw-r--r--. 1 root root 576 May  4 12:10 /home/acme/lib/examples/perf/bpf/empty.o
        # file ~acme/lib/examples/perf/bpf/empty.o
        /home/acme/lib/examples/perf/bpf/empty.o: ELF 64-bit LSB relocatable, *unknown arch 0xf7* version 1 (SYSV), not stripped
        # readelf -sw ~acme/lib/examples/perf/bpf/empty.o
      
        Symbol table '.symtab' contains 3 entries:
           Num:    Value          Size Type    Bind   Vis      Ndx Name
             0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
             1: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT    3 _license
             2: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT    4 _version
        #
        # tools/bpf/bpftool/bpftool --pretty ~acme/lib/examples/perf/bpf/empty.o
        null
        #
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-y7dkhakejz3013o0w21n98xd@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8f12a2ff
    • A
      perf llvm-utils: Add bpf include path to clang command line · 1b16fffa
      Arnaldo Carvalho de Melo 提交于
      We'll start putting headers for helpers to be used in eBPF proggies in
      there:
      
        # perf trace -v --no-syscalls -e empty.c |& grep "llvm compiling command : "
        llvm compiling command : /usr/lib64/ccache/clang -D__KERNEL__ -D__NR_CPUS__=4 -DLINUX_VERSION_CODE=0x41100   -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include -I/home/acme/git/linux/arch/x86/include -I./arch/x86/include/generated  -I/home/acme/git/linux/include -I./include -I/home/acme/git/linux/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/home/acme/git/linux/include/uapi -I./include/generated/uapi -include /home/acme/git/linux/include/linux/kconfig.h  -I/home/acme/lib/include/perf/bpf -Wno-unused-value -Wno-pointer-sign -working-directory /lib/modules/4.17.0-rc3-00034-gf4ef6a43/build -c /home/acme/bpf/empty.c -target bpf -O2 -o -
        #
      
      Notice the "-I/home/acme/lib/include/perf/bpf"
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-6xq94xro8xlb5s9urznh3f9k@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1b16fffa
  20. 09 4月, 2018 1 次提交
  21. 08 3月, 2018 1 次提交
  22. 22 2月, 2018 1 次提交
    • M
      tools: fix cross-compile var clobbering · 7ed1c190
      Martin Kelly 提交于
      Currently a number of Makefiles break when used with toolchains that
      pass extra flags in CC and other cross-compile related variables (such
      as --sysroot).
      
      Thus we get this error when we use a toolchain that puts --sysroot in
      the CC var:
      
        ~/src/linux/tools$ make iio
        [snip]
        iio_event_monitor.c:18:10: fatal error: unistd.h: No such file or directory
          #include <unistd.h>
                   ^~~~~~~~~~
      
      This occurs because we clobber several env vars related to
      cross-compiling with lines like this:
      
        CC = $(CROSS_COMPILE)gcc
      
      Although this will point to a valid cross-compiler, we lose any extra
      flags that might exist in the CC variable, which can break toolchains
      that rely on them (for example, those that use --sysroot).
      
      This easily shows up using a Yocto SDK:
      
        $ . [snip]/sdk/environment-setup-cortexa8hf-neon-poky-linux-gnueabi
      
        $ echo $CC
        arm-poky-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard
        -mcpu=cortex-a8
        --sysroot=[snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi
      
        $ echo $CROSS_COMPILE
        arm-poky-linux-gnueabi-
      
        $ echo ${CROSS_COMPILE}gcc
        krm-poky-linux-gnueabi-gcc
      
      Although arm-poky-linux-gnueabi-gcc is a cross-compiler, we've lost the
      --sysroot and other flags that enable us to find the right libraries to
      link against, so we can't find unistd.h and other libraries and headers.
      Normally with the --sysroot flag we would find unistd.h in the sdk
      directory in the sysroot:
      
        $ find [snip]/sdk/sysroots -path '*/usr/include/unistd.h'
        [snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi/usr/include/unistd.h
      
      The perf Makefile adds CC = $(CROSS_COMPILE)gcc if and only if CC is not
      already set, and it compiles correctly with the above toolchain.
      
      So, generalize the logic that perf uses in the common Makefile and
      remove the manual CC = $(CROSS_COMPILE)gcc lines from each Makefile.
      
      Note that this patch does not fix cross-compile for all the tools (some
      have other bugs), but it does fix it for all except usb and acpi, which
      still have other unrelated issues.
      
      I tested both with and without the patch on native and cross-build and
      there appear to be no regressions.
      
      Link: http://lkml.kernel.org/r/20180107214028.23771-1-martin@martingkelly.comSigned-off-by: NMartin Kelly <martin@martingkelly.com>
      Acked-by: NMark Brown <broonie@kernel.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Li Zefan <lizefan@huawei.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: Jonathan Cameron <jic23@kernel.org>
      Cc: Pali Rohar <pali.rohar@gmail.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Lv Zheng <lv.zheng@intel.com>
      Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Valentina Manea <valentina.manea.m@gmail.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Mario Limonciello <mario.limonciello@dell.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7ed1c190
  23. 19 2月, 2018 1 次提交
    • J
      perf tools: Add Python 3 support · 66dfdff0
      Jaroslav Škarvada 提交于
      Added Python 3 support while keeping Python 2.7 compatibility.
      
      Committer notes:
      
      This doesn't make it to auto detect python 3, one has to explicitely ask
      it to build with python 3 devel files, here are the instructions
      provided by Jaroslav:
      
       ---
        $ cp -a tools/perf tools/python3-perf
        $ make V=1 prefix=/usr -C tools/perf PYTHON=/usr/bin/python2 all
        $ make V=1 prefix=/usr -C tools/python3-perf PYTHON=/usr/bin/python3 all
        $ make V=1 prefix=/usr -C tools/python3-perf PYTHON=/usr/bin/python3 DESTDIR=%{buildroot} install-python_ext
        $ make V=1 prefix=/usr -C tools/perf PYTHON=/usr/bin/python2 DESTDIR=%{buildroot} install-python_ext
       ---
      
      We need to make this automatic, just like the existing tests for checking if
      the python2 devel files are in place, allowing the build with python3 if
      available, fallbacking to python2 and then just disabling it if none are
      available.
      
      So, using the PYTHON variable to build it using O= we get:
      
      Before this patch:
      
        $ rpm -q python3 python3-devel
        python3-3.6.4-7.fc27.x86_64
        python3-devel-3.6.4-7.fc27.x86_64
        $ rm -rf /tmp/build/perf/ ; mkdir -p /tmp/build/perf ; make O=/tmp/build/perf PYTHON=/usr/bin/python3 -C tools/perf install-bin
        make: Entering directory '/home/acme/git/linux/tools/perf'
        <SNIP>
        Makefile.config:670: Python 3 is not yet supported; please set
        Makefile.config:671: PYTHON and/or PYTHON_CONFIG appropriately.
        Makefile.config:672: If you also have Python 2 installed, then
        Makefile.config:673: try something like:
        Makefile.config:674:
        Makefile.config:675:   make PYTHON=python2
        Makefile.config:676:
        Makefile.config:677: Otherwise, disable Python support entirely:
        Makefile.config:678:
        Makefile.config:679:   make NO_LIBPYTHON=1
        Makefile.config:680:
        Makefile.config:681: *** .  Stop.
        make[1]: *** [Makefile.perf:212: sub-make] Error 2
        make: *** [Makefile:110: install-bin] Error 2
        make: Leaving directory '/home/acme/git/linux/tools/perf'
        $
      
      After:
      
        $ make O=/tmp/build/perf PYTHON=python3 -C tools/perf install-bin
        $ ldd ~/bin/perf | grep python
      	libpython3.6m.so.1.0 => /lib64/libpython3.6m.so.1.0 (0x00007f58a31e8000)
        $ rpm -qf /lib64/libpython3.6m.so.1.0
        python3-libs-3.6.4-7.fc27.x86_64
        $
      
      Now verify that when using the binding the right ELF file is loaded,
      using perf trace:
      
        $ perf trace -e open* perf test python
           0.051 ( 0.016 ms): perf/3927 openat(dfd: CWD, filename: /etc/ld.so.cache, flags: CLOEXEC           ) = 3
      <SNIP>
        18: 'import perf' in python                               :
           8.849 ( 0.013 ms): sh/3929 openat(dfd: CWD, filename: /etc/ld.so.cache, flags: CLOEXEC           ) = 3
      <SNIP>
          25.572 ( 0.008 ms): python3/3931 openat(dfd: CWD, filename: /tmp/build/perf/python/perf.cpython-36m-x86_64-linux-gnu.so, flags: CLOEXEC) = 3
      <SNIP>
       Ok
      <SNIP>
        $
      
      And using tools/perf/python/twatch.py, to show PERF_RECORD_ metaevents:
      
        $ python3 tools/perf/python/twatch.py
        cpu: 3, pid: 16060, tid: 16060 { type: fork, pid: 5207, ppid: 16060, tid: 5207, ptid: 16060, time: 10798513015459}
        cpu: 3, pid: 16060, tid: 16060 { type: fork, pid: 5208, ppid: 16060, tid: 5208, ptid: 16060, time: 10798513562503}
        cpu: 0, pid: 5208, tid: 5208 { type: comm, pid: 5208, tid: 5208, comm: grep }
        cpu: 2, pid: 5207, tid: 5207 { type: comm, pid: 5207, tid: 5207, comm: ps }
        cpu: 2, pid: 5207, tid: 5207 { type: exit, pid: 5207, ppid: 5207, tid: 5207, ptid: 5207, time: 10798551337484}
        cpu: 3, pid: 5208, tid: 5208 { type: exit, pid: 5208, ppid: 5208, tid: 5208, ptid: 5208, time: 10798551292153}
        cpu: 3, pid: 601, tid: 601 { type: fork, pid: 5209, ppid: 601, tid: 5209, ptid: 601, time: 10801779977324}
        ^CTraceback (most recent call last):
          File "tools/perf/python/twatch.py", line 68, in <module>
            main()
          File "tools/perf/python/twatch.py", line 40, in main
            evlist.poll(timeout = -1)
        KeyboardInterrupt
        $
      
        # ps ax|grep twatch
       5197 pts/8    S+     0:00 python3 tools/perf/python/twatch.py
        # ls -la /proc/5197/smaps
        -r--r--r--. 1 acme acme 0 Feb 19 13:14 /proc/5197/smaps
        # grep python /proc/5197/smaps
        558111307000-558111309000 r-xp 00000000 fd:00 3151710  /usr/bin/python3.6
        558111508000-558111509000 r--p 00001000 fd:00 3151710  /usr/bin/python3.6
        558111509000-55811150a000 rw-p 00002000 fd:00 3151710  /usr/bin/python3.6
        7ffad6fc1000-7ffad7008000 r-xp 00000000 00:2d 220196   /tmp/build/perf/python/perf.cpython-36m-x86_64-linux-gnu.so
        7ffad7008000-7ffad7207000 ---p 00047000 00:2d 220196   /tmp/build/perf/python/perf.cpython-36m-x86_64-linux-gnu.so
        7ffad7207000-7ffad7208000 r--p 00046000 00:2d 220196   /tmp/build/perf/python/perf.cpython-36m-x86_64-linux-gnu.so
        7ffad7208000-7ffad7215000 rw-p 00047000 00:2d 220196   /tmp/build/perf/python/perf.cpython-36m-x86_64-linux-gnu.so
        7ffadea77000-7ffaded3d000 r-xp 00000000 fd:00 3151795  /usr/lib64/libpython3.6m.so.1.0
        7ffaded3d000-7ffadef3c000 ---p 002c6000 fd:00 3151795  /usr/lib64/libpython3.6m.so.1.0
        7ffadef3c000-7ffadef42000 r--p 002c5000 fd:00 3151795  /usr/lib64/libpython3.6m.so.1.0
        7ffadef42000-7ffadefa5000 rw-p 002cb000 fd:00 3151795  /usr/lib64/libpython3.6m.so.1.0
        #
      
      And with this patch, but building normally, without specifying the
      PYTHON=python3 part, which will make it use python2 if its devel files are
      available, like in this test:
      
        $ make O=/tmp/build/perf -C tools/perf install-bin
        $ ldd ~/bin/perf | grep python
      	libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007f6a44410000)
        $ ldd /tmp/build/perf/python_ext_build/lib/perf.so  | grep python
      	libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007fed28a2c000)
        $
      
        [acme@jouet perf]$ tools/perf/python/twatch.py
        cpu: 0, pid: 2817, tid: 2817 { type: fork, pid: 2817, ppid: 2817, tid: 8910, ptid: 2817, time: 11126454335306}
        cpu: 0, pid: 2817, tid: 2817 { type: comm, pid: 2817, tid: 8910, comm: worker }
        $ ps ax | grep twatch.py
         8909 pts/8    S+     0:00 /usr/bin/python tools/perf/python/twatch.py
        $ grep python /proc/8909/smaps
        5579de658000-5579de659000 r-xp 00000000 fd:00 3156044  /usr/bin/python2.7
        5579de858000-5579de859000 r--p 00000000 fd:00 3156044  /usr/bin/python2.7
        5579de859000-5579de85a000 rw-p 00001000 fd:00 3156044  /usr/bin/python2.7
        7f0de01f7000-7f0de023e000 r-xp 00000000 00:2d 230695   /tmp/build/perf/python/perf.so
        7f0de023e000-7f0de043d000 ---p 00047000 00:2d 230695   /tmp/build/perf/python/perf.so
        7f0de043d000-7f0de043e000 r--p 00046000 00:2d 230695   /tmp/build/perf/python/perf.so
        7f0de043e000-7f0de044b000 rw-p 00047000 00:2d 230695   /tmp/build/perf/python/perf.so
        7f0de6f0f000-7f0de6f13000 r-xp 00000000 fd:00 134975   /usr/lib64/python2.7/lib-dynload/_localemodule.so
        7f0de6f13000-7f0de7113000 ---p 00004000 fd:00 134975   /usr/lib64/python2.7/lib-dynload/_localemodule.so
        7f0de7113000-7f0de7114000 r--p 00004000 fd:00 134975   /usr/lib64/python2.7/lib-dynload/_localemodule.so
        7f0de7114000-7f0de7115000 rw-p 00005000 fd:00 134975   /usr/lib64/python2.7/lib-dynload/_localemodule.so
        7f0de7e73000-7f0de8052000 r-xp 00000000 fd:00 3173292  /usr/lib64/libpython2.7.so.1.0
        7f0de8052000-7f0de8251000 ---p 001df000 fd:00 3173292  /usr/lib64/libpython2.7.so.1.0
        7f0de8251000-7f0de8255000 r--p 001de000 fd:00 3173292  /usr/lib64/libpython2.7.so.1.0
        7f0de8255000-7f0de8291000 rw-p 001e2000 fd:00 3173292  /usr/lib64/libpython2.7.so.1.0
        $
      Signed-off-by: NJaroslav Škarvada <jskarvad@redhat.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      LPU-Reference: 20180119205641.24242-1-jskarvad@redhat.com
      Link: https://lkml.kernel.org/n/tip-8d7dt9kqp83vsz25hagug8fu@git.kernel.org
      [ Removed explicit check for python version, allowing it to really build with python3 ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      66dfdff0
  24. 25 1月, 2018 1 次提交
  25. 23 1月, 2018 1 次提交
  26. 08 1月, 2018 1 次提交
  27. 01 11月, 2017 1 次提交
    • A
      perf trace beauty kcmp: Beautify arguments · 1de3038d
      Arnaldo Carvalho de Melo 提交于
      For some unknown reason there is no entry in tracefs's syscalls for
      kcmp, i.e. no tracefs/events/syscalls/sys_{enter,exit}_kcmp, so we need
      to provide a data dictionary for the fields.
      
      To beautify the 'type' argument we automatically generate a strarray
      from tools/include/uapi/kcmp.h, the idx1 and idx2 args, nowadays used
      only if type == KCMP_FILE, are masked for all the other types and a
      lookup is made for the thread and fd to show the path, if possible,
      getting it from the probe:vfs_getname if in place or from procfs, races
      allowing.
      
      A system wide strace like tracing session, with callchains shows just
      one user so far in this fedora 25 machine:
      
        # perf trace --max-stack 5 -e kcmp
        <SNIP>
        1502914.400 ( 0.001 ms): systemd/1 kcmp(pid1: 1 (systemd), pid2: 1 (systemd), type: FILE, idx1: 271<socket:[4723475]>, idx2: 25<socket:[4788686]>) = -1 ENOSYS Function not implemented
                                               syscall (/usr/lib64/libc-2.25.so)
                                               same_fd (/usr/lib/systemd/libsystemd-shared-233.so)
                                               service_add_fd_store (/usr/lib/systemd/systemd)
                                               service_notify_message.lto_priv.127 (/usr/lib/systemd/systemd)
        1502914.407 ( 0.001 ms): systemd/1 kcmp(pid1: 1 (systemd), pid2: 1 (systemd), type: FILE, idx1: 270<socket:[4726396]>, idx2: 25<socket:[4788686]>) = -1 ENOSYS Function not implemented
                                               syscall (/usr/lib64/libc-2.25.so)
                                               same_fd (/usr/lib/systemd/libsystemd-shared-233.so)
                                               service_add_fd_store (/usr/lib/systemd/systemd)
                                               service_notify_message.lto_priv.127 (/usr/lib/systemd/systemd)
        <SNIP>
      
      The backtraces seem to agree this is really kcmp(), but this system
      doesn't have the sys_kcmp(), bummer:
      
        # uname -a
        Linux jouet 4.14.0-rc3+ #1 SMP Fri Oct 13 12:21:12 -03 2017 x86_64 x86_64 x86_64 GNU/Linux
        # grep kcmp /proc/kallsyms
        ffffffffb60b8890 W sys_kcmp
        $ grep CONFIG_CHECKPOINT_RESTORE ../build/v4.14.0-rc3+/.config
        # CONFIG_CHECKPOINT_RESTORE is not set
        $
      
      So systemd uses it, good fedora kernel config has it:
      
        $ grep CONFIG_CHECKPOINT_RESTORE /boot/config-4.13.4-200.fc26.x86_64
        CONFIG_CHECKPOINT_RESTORE=y
        [acme@jouet linux]$
      
      /me goes to rebuild a kernel...
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Andrey Vagin <avagin@openvz.org>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-gz5fca968viw8m7hryjqvrln@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1de3038d
  28. 27 10月, 2017 1 次提交
    • A
      perf trace beauty prctl: Generate 'option' string table from kernel headers · d688d037
      Arnaldo Carvalho de Melo 提交于
      This is one more case where the way that syscall parameter values are
      defined in kernel headers are easy to parse using a shell script that
      will then generate the string table that gets used by the prctl 'option'
      argument beautifier.
      
      This way as soon as the header syncronization mechanism in perf's build
      system detects a change in a copy of a kernel ABI header and that file
      is syncronized, we get 'perf trace' updated automagically.
      
      Further work needed for the PR_SET_ values, as well for using eBPF to
      copy the non-integer arguments to/from the kernel.
      
      E.g.: System wide prctl tracing:
      
        # perf trace -e prctl
        1668.028 ( 0.025 ms): TaskSchedulerR/10649 prctl(option: SET_NAME, arg2: 0x2b61d5db15d0) = 0
        3365.663 ( 0.018 ms): chrome/10650 prctl(option: SET_SECCOMP, arg2: 2, arg4: 8         ) = -1 EFAULT Bad address
        3366.585 ( 0.010 ms): chrome/10650 prctl(option: SET_NO_NEW_PRIVS, arg2: 1             ) = 0
        3367.173 ( 0.009 ms): TaskSchedulerR/10652 prctl(option: SET_NAME, arg2: 0x2b61d2aaa300) = 0
        3367.222 ( 0.003 ms): TaskSchedulerR/10653 prctl(option: SET_NAME, arg2: 0x2b61d2aaa1e0) = 0
        3367.244 ( 0.002 ms): TaskSchedulerR/10654 prctl(option: SET_NAME, arg2: 0x2b61d2aaa0c0) = 0
        3367.265 ( 0.002 ms): TaskSchedulerR/10655 prctl(option: SET_NAME, arg2: 0x2b61d2ac7f90) = 0
        3367.281 ( 0.002 ms): Chrome_ChildIO/10656 prctl(option: SET_NAME, arg2: 0x7efbe406bb11) = 0
        3367.220 ( 0.004 ms): TaskSchedulerS/10651 prctl(option: SET_NAME, arg2: 0x2b61d2ac1be0) = 0
        3370.906 ( 0.010 ms): GpuMemoryThrea/10657 prctl(option: SET_NAME, arg2: 0x7efbe386ab11) = 0
        3370.983 ( 0.003 ms): File/10658 prctl(option: SET_NAME, arg2: 0x7efbe3069b11          ) = 0
        3384.272 ( 0.020 ms): Compositor/10659 prctl(option: SET_NAME, arg2: 0x7efbe2868b11    ) = 0
        3612.091 ( 0.012 ms): DOM Worker/11489 prctl(option: SET_NAME, arg2: 0x7f49ab97ebf2    ) = 0
      <SNIP>
        4512.437 ( 0.004 ms): (sa1)/11490 prctl(option: SET_NAME, arg2: 0x7ffca15af844         ) = 0
        4512.468 ( 0.002 ms): (sa1)/11490 prctl(option: SET_MM, arg2: ARG_START, arg3: 0x7f5cb7c81000) = 0
        4512.472 ( 0.001 ms): (sa1)/11490 prctl(option: SET_MM, arg2: ARG_END, arg3: 0x7f5cb7c81006) = 0
        4514.667 ( 0.002 ms): (sa1)/11490 prctl(option: GET_SECUREBITS                         ) = 0
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-q0s2uw579o5ei6xlh2zjirgz@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d688d037
  29. 22 9月, 2017 1 次提交
    • A
      perf trace beauty madvise: Generate 'behavior' string table from kernel headers · 5a54c2f5
      Arnaldo Carvalho de Melo 提交于
      This is one more case where the way that syscall parameter values are
      defined in kernel headers are easy to parse using a shell script that
      will then generate the string table that gets used by the madvise
      'behaviour' argument beautifier.
      
      This way as soon as the header syncronization mechanism in perf's build
      system detects a change in a copy of a kernel ABI header and that file
      is syncronized, we get 'perf trace' updated automagically.
      
      So, when we syncronize this:
      
        Warning: Kernel ABI header at 'tools/include/uapi/asm-generic/mman-common.h' differs from latest version at 'include/uapi/asm-generic/mman-common.h'
      
      We'll get these:
      
        #define MADV_WIPEONFORK 18              /* Zero memory on fork, child only */
        #define MADV_KEEPONFORK 19              /* Undo MADV_WIPEONFORK */
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-dolb0ghds4ui7wc1npgkchvc@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5a54c2f5
  30. 13 9月, 2017 1 次提交