1. 07 12月, 2016 8 次提交
    • N
      perf sched timehist: Handle zero sample->tid properly · 5d92d96a
      Namhyung Kim 提交于
      Sometimes samples have tid of 0 but non-0 pid.  It ends up having a new
      thread of 0 tid/pid (instead of referring idle task) since tid is used
      to search matching task.  But I guess it's wrong to use 0 as a tid when
      pid is set.  This patch uses tid only if it has a non-zero value or same
      as pid (of 0).
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20161206034010.6499-4-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5d92d96a
    • N
      perf callchain: Introduce callchain_cursor__copy() · 571f1eb9
      Namhyung Kim 提交于
      The callchain_cursor__copy() function is to save current callchain
      captured by a cursor.  It'll be used to keep callchains when switching
      to idle task for each cpu.
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20161206034010.6499-3-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      571f1eb9
    • N
      perf sched: Cleanup option processing · 6fa94258
      Namhyung Kim 提交于
      The -D/--dump-raw-trace option is in the parent option so no need to
      repeat it.  Also move -f/--force option to parent as it's common to
      handle data file.
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20161206034010.6499-2-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6fa94258
    • D
      perf sched timehist: Improve error message when analyzing wrong file · f45bf8d3
      David Ahern 提交于
      Arnaldo reported an unhelpful error message when running perf sched
      timehist on a file that did not contain sched tracepoints:
      
          [root@jouet ~]# perf sched timehist
          No trace sample to read. Did you call 'perf record -R'?
      
          [root@jouet ~]# perf evlist -v
          cycles:ppp: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CALLCHAIN|CPU|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1
      
      Change the has_traces check to look for the sched_switch event. Analysis
      for perf sched timehist requires at least this event.
      
      Now when analyzing a file without sched tracepoints you get:
      
          root@f21-vbox:/tmp$ perf sched timehist
          No sched_switch events found. Have you run 'perf sched record'?
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Reported-and-Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Acked-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1480451988-43673-1-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f45bf8d3
    • J
      perf tools: Move perf build related variables under non fixdep leg · 8ac1eb7b
      Jiri Olsa 提交于
      Because there's no need for them in fixdep build.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1481030331-31944-4-git-send-email-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8ac1eb7b
    • J
      perf tools: Force fixdep compilation at the start of the build · abb26210
      Jiri Olsa 提交于
      The fixdep tool needs to be built before everything else, because it fixes
      every object dependency file.
      
      We handle this currently by making all objects to depend on fixdep, which is
      error prone and is easily forgotten when new object is added.
      
      Instead of this, this patch force fixdep tool to be built as the first target
      in the separate make session. This way we don't need to handle extra fixdep
      dependencies and we are certain there's no fixdep race with any parallel make
      job.
      
      Committer notes:
      
      Testing it:
      
      Before:
      
        $ rm -rf /tmp/build/perf/ ; mkdir -p /tmp/build/perf ; make -k O=/tmp/build/perf -C tools/perf install-bin
        make: Entering directory '/home/acme/git/linux/tools/perf'
          BUILD:   Doing 'make -j4' parallel build
      
        Auto-detecting system features:
        ...                         dwarf: [ on  ]
        ...            dwarf_getlocations: [ on  ]
        ...                         glibc: [ on  ]
        ...                          gtk2: [ on  ]
        ...                      libaudit: [ on  ]
        ...                        libbfd: [ on  ]
        ...                        libelf: [ on  ]
        ...                       libnuma: [ on  ]
        ...        numa_num_possible_cpus: [ on  ]
        ...                       libperl: [ on  ]
        ...                     libpython: [ on  ]
        ...                      libslang: [ on  ]
        ...                     libcrypto: [ on  ]
        ...                     libunwind: [ on  ]
        ...            libdw-dwarf-unwind: [ on  ]
        ...                          zlib: [ on  ]
        ...                          lzma: [ on  ]
        ...                     get_cpuid: [ on  ]
        ...                           bpf: [ on  ]
      
          GEN      /tmp/build/perf/common-cmds.h
          HOSTCC   /tmp/build/perf/fixdep.o
          HOSTLD   /tmp/build/perf/fixdep-in.o
          LINK     /tmp/build/perf/fixdep
          MKDIR    /tmp/build/perf/pmu-events/
          HOSTCC   /tmp/build/perf/pmu-events/json.o
          MKDIR    /tmp/build/perf/pmu-events/
          HOSTCC   /tmp/build/perf/pmu-events/jsmn.o
          HOSTCC   /tmp/build/perf/pmu-events/jevents.o
          HOSTLD   /tmp/build/perf/pmu-events/jevents-in.o
          PERF_VERSION = 4.9.rc8.g868cd5
          CC       /tmp/build/perf/perf-read-vdso32
        <SNIP>
      
      After:
      
        $ rm -rf /tmp/build/perf/ ; mkdir -p /tmp/build/perf ; make -k O=/tmp/build/perf -C tools/perf install-bin
        make: Entering directory '/home/acme/git/linux/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  ]
        ...            dwarf_getlocations: [ on  ]
        ...                         glibc: [ on  ]
        ...                          gtk2: [ on  ]
        ...                      libaudit: [ on  ]
        ...                        libbfd: [ on  ]
        ...                        libelf: [ on  ]
        ...                       libnuma: [ on  ]
        ...        numa_num_possible_cpus: [ on  ]
        ...                       libperl: [ on  ]
        ...                     libpython: [ on  ]
        ...                      libslang: [ on  ]
        ...                     libcrypto: [ on  ]
        ...                     libunwind: [ on  ]
        ...            libdw-dwarf-unwind: [ on  ]
        ...                          zlib: [ on  ]
        ...                          lzma: [ on  ]
        ...                     get_cpuid: [ on  ]
        ...                           bpf: [ on  ]
      
          GEN      /tmp/build/perf/common-cmds.h
          MKDIR    /tmp/build/perf/fd/
          CC       /tmp/build/perf/fd/array.o
          LD       /tmp/build/perf/fd/libapi-in.o
          MKDIR    /tmp/build/perf/fs/
          CC       /tmp/build/perf/event-parse.o
          CC       /tmp/build/perf/fs/fs.o
          PERF_VERSION = 4.9.rc8.g57a92f
          CC       /tmp/build/perf/event-plugin.o
          MKDIR    /tmp/build/perf/fs/
          CC       /tmp/build/perf/fs/tracing_path.o
        <SNIP>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1481030331-31944-3-git-send-email-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      abb26210
    • J
      perf tools: Move PERF-VERSION-FILE target into rules area · 16e2ef4e
      Jiri Olsa 提交于
      An upcoming fixdep fix needs all targets at the same area, so they'll
      fit under a signal condition block.
      
      Moving PERF-VERSION-FILE target into rules section.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1481030331-31944-2-git-send-email-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      16e2ef4e
    • W
      perf build: Check LLVM version in feature check · a940cad3
      Wang Nan 提交于
      Cancel builtin llvm and clang support when LLVM version is less than
      3.9.0: following commits uses newer API.
      
      Since Clang/LLVM's API is not guaranteed to be stable, add a
      test-llvm-version.cpp feature checker, issue warning if LLVM found in
      compiling environment is not tested yet.
      
      Committer Notes:
      
      Testing it:
      
      Environment:
      
        $ cat /etc/fedora-release
        Fedora release 25 (Twenty Five)
        $ rpm -q llvm-devel clang-devel
        llvm-devel-3.8.0-1.fc25.x86_64
        clang-devel-3.8.0-2.fc25.x86_64
        $
      
      Before:
      
        $  make -k LIBCLANGLLVM=1 O=/tmp/build/perf -C tools/perf install-bin
        make: Entering directory '/home/acme/git/linux/tools/perf'
          BUILD:   Doing 'make -j4' parallel build
        Warning: tools/include/uapi/linux/bpf.h differs from kernel
        Warning: tools/arch/arm/include/uapi/asm/kvm.h differs from kernel
          INSTALL  GTK UI
          LINK     /tmp/build/perf/perf
        /tmp/build/perf/libperf.a(libperf-in.o): In function `perf::createCompilerInvocation(llvm::SmallVector<char const*, 16u>, llvm::StringRef&, clang::DiagnosticsEngine&)':
        /home/acme/git/linux/tools/perf/util/c++/clang.cpp:56: undefined reference to `clang::tooling::newInvocation(clang::DiagnosticsEngine*, llvm::SmallVector<char const*, 16u> const&)'
        /tmp/build/perf/libperf.a(libperf-in.o): In function `perf::getModuleFromSource(llvm::SmallVector<char const*, 16u>, llvm::StringRef, llvm::IntrusiveRefCntPtr<clang::vfs::FileSystem>)':
        /home/acme/git/linux/tools/perf/util/c++/clang.cpp:68: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, bool)'
        /home/acme/git/linux/tools/perf/util/c++/clang.cpp:69: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'
        <SNIP>
      
      After:
      
        Makefile.config:807: No suitable libLLVM found, disabling builtin clang and llvm support. Please install llvm-dev(el) (>= 3.9.0)
      
      Updating the environment to a locally built LLVM 4.0 + clang 3.9 (forgot
      to git pull, duh) combo, all works as expected, it is properly detected
      and built into the resulting perf binary.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Reported-and-Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexei Starovoitov <ast@fb.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Joe Stringer <joe@ovn.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/20161206072230.7651-1-wangnan0@huawei.com
      [ Change the warning message a bit (add 'suitable' and 'builtin'), clarifying it, see committer notes above ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a940cad3
  2. 06 12月, 2016 24 次提交
  3. 05 12月, 2016 1 次提交
  4. 04 12月, 2016 2 次提交
  5. 03 12月, 2016 5 次提交
    • L
      Merge branch 'akpm' (patches from Andrew) · 3c49de52
      Linus Torvalds 提交于
      Merge more fixes from Andrew Morton:
       "2 fixes"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        mm, vmscan: add cond_resched() into shrink_node_memcg()
        mm: workingset: fix NULL ptr in count_shadow_nodes
      3c49de52
    • M
      mm, vmscan: add cond_resched() into shrink_node_memcg() · bd041733
      Michal Hocko 提交于
      Boris Zhmurov has reported RCU stalls during the kswapd reclaim:
      
        INFO: rcu_sched detected stalls on CPUs/tasks:
         23-...: (22 ticks this GP) idle=92f/140000000000000/0 softirq=2638404/2638404 fqs=23
         (detected by 4, t=6389 jiffies, g=786259, c=786258, q=42115)
        Task dump for CPU 23:
        kswapd1         R  running task        0   148      2 0x00000008
        Call Trace:
          shrink_node+0xd2/0x2f0
          kswapd+0x2cb/0x6a0
          mem_cgroup_shrink_node+0x160/0x160
          kthread+0xbd/0xe0
          __switch_to+0x1fa/0x5c0
          ret_from_fork+0x1f/0x40
          kthread_create_on_node+0x180/0x180
      
      a closer code inspection has shown that we might indeed miss all the
      scheduling points in the reclaim path if no pages can be isolated from
      the LRU list.  This is a pathological case but other reports from Donald
      Buczek have shown that we might indeed hit such a path:
      
              clusterd-989   [009] .... 118023.654491: mm_vmscan_direct_reclaim_end: nr_reclaimed=193
               kswapd1-86    [001] dN.. 118023.987475: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4239830 nr_taken=0 file=1
               kswapd1-86    [001] dN.. 118024.320968: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4239844 nr_taken=0 file=1
               kswapd1-86    [001] dN.. 118024.654375: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4239858 nr_taken=0 file=1
               kswapd1-86    [001] dN.. 118024.987036: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4239872 nr_taken=0 file=1
               kswapd1-86    [001] dN.. 118025.319651: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4239886 nr_taken=0 file=1
               kswapd1-86    [001] dN.. 118025.652248: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4239900 nr_taken=0 file=1
               kswapd1-86    [001] dN.. 118025.984870: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4239914 nr_taken=0 file=1
        [...]
               kswapd1-86    [001] dN.. 118084.274403: mm_vmscan_lru_isolate: isolate_mode=0 classzone=0 order=0 nr_requested=32 nr_scanned=4241133 nr_taken=0 file=1
      
      this is minute long snapshot which didn't take a single page from the
      LRU.  It is not entirely clear why only 1303 pages have been scanned
      during that time (maybe there was a heavy IRQ activity interfering).
      
      In any case it looks like we can really hit long periods without
      scheduling on non preemptive kernels so an explicit cond_resched() in
      shrink_node_memcg which is independent on the reclaim operation is due.
      
      Link: http://lkml.kernel.org/r/20161202095841.16648-1-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
      Reported-by: NBoris Zhmurov <bb@kernelpanic.ru>
      Tested-by: NBoris Zhmurov <bb@kernelpanic.ru>
      Reported-by: NDonald Buczek <buczek@molgen.mpg.de>
      Reported-by: N"Christopher S. Aker" <caker@theshore.net>
      Reported-by: NPaul Menzel <pmenzel@molgen.mpg.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bd041733
    • M
      mm: workingset: fix NULL ptr in count_shadow_nodes · 20ab67a5
      Michal Hocko 提交于
      Commit 0a6b76dd ("mm: workingset: make shadow node shrinker memcg
      aware") has made the workingset shadow nodes shrinker memcg aware.  The
      implementation is not correct though because memcg_kmem_enabled() might
      become true while we are doing a global reclaim when the sc->memcg might
      be NULL which is exactly what Marek has seen:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000400
        IP: [<ffffffff8122d520>] mem_cgroup_node_nr_lru_pages+0x20/0x40
        PGD 0
        Oops: 0000 [#1] SMP
        CPU: 0 PID: 60 Comm: kswapd0 Tainted: G           O   4.8.10-12.pvops.qubes.x86_64 #1
        task: ffff880011863b00 task.stack: ffff880011868000
        RIP: mem_cgroup_node_nr_lru_pages+0x20/0x40
        RSP: e02b:ffff88001186bc70  EFLAGS: 00010293
        RAX: 0000000000000000 RBX: ffff88001186bd20 RCX: 0000000000000002
        RDX: 000000000000000c RSI: 0000000000000000 RDI: 0000000000000000
        RBP: ffff88001186bc70 R08: 28f5c28f5c28f5c3 R09: 0000000000000000
        R10: 0000000000006c34 R11: 0000000000000333 R12: 00000000000001f6
        R13: ffffffff81c6f6a0 R14: 0000000000000000 R15: 0000000000000000
        FS:  0000000000000000(0000) GS:ffff880013c00000(0000) knlGS:ffff880013d00000
        CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000000400 CR3: 00000000122f2000 CR4: 0000000000042660
        Call Trace:
          count_shadow_nodes+0x9a/0xa0
          shrink_slab.part.42+0x119/0x3e0
          shrink_node+0x22c/0x320
          kswapd+0x32c/0x700
          kthread+0xd8/0xf0
          ret_from_fork+0x1f/0x40
        Code: 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 3b 35 dd eb b1 00 55 48 89 e5 73 2c 89 d2 31 c9 31 c0 4c 63 ce 48 0f a3 ca 73 13 <4a> 8b b4 cf 00 04 00 00 41 89 c8 4a 03 84 c6 80 00 00 00 83 c1
        RIP  mem_cgroup_node_nr_lru_pages+0x20/0x40
         RSP <ffff88001186bc70>
        CR2: 0000000000000400
        ---[ end trace 100494b9edbdfc4d ]---
      
      This patch fixes the issue by checking sc->memcg rather than
      memcg_kmem_enabled() which is sufficient because shrink_slab makes sure
      that only memcg aware shrinkers will get non-NULL memcgs and only if
      memcg_kmem_enabled is true.
      
      Fixes: 0a6b76dd ("mm: workingset: make shadow node shrinker memcg aware")
      Link: http://lkml.kernel.org/r/20161201132156.21450-1-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
      Reported-by: NMarek Marczykowski-Górecki <marmarek@mimuw.edu.pl>
      Tested-by: NMarek Marczykowski-Górecki <marmarek@mimuw.edu.pl>
      Acked-by: NVladimir Davydov <vdavydov.dev@gmail.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: NBalbir Singh <bsingharora@gmail.com>
      Cc: <stable@vger.kernel.org>	[4.6+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      20ab67a5
    • N
      kbuild: fix building bzImage with CONFIG_TRIM_UNUSED_KSYMS enabled · 86556392
      Nicolas Pitre 提交于
      When building a specific target such as bzImage, modules aren't normally
      built.  However if CONFIG_TRIM_UNUSED_KSYMS is enabled, no built modules
      means none of the exported symbols are used and therefore they will all
      be trimmed away from the final kernel.  A subsequent "make modules" will
      fail because modpost cannot find the needed symbols for those modules in
      the kernel binary.
      
      Let's make sure modules are also built whenever CONFIG_TRIM_UNUSED_KSYMS
      is enabled and that the kernel binary is properly rebuilt accordingly.
      Signed-off-by: NNicolas Pitre <nico@linaro.org>
      Tested-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      86556392
    • L
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 8dc0f265
      Linus Torvalds 提交于
      Pull ARM SoC fixes from Arnd Bergmann:
       "This should be the last set of bugfixes for arm-soc in v4.9. None of
        these are critical regressions, but it would be nice to still get them
        merged.
      
         - On the Juno platform, the idle latency was described wrong, leading
           to suboptimal cpuidle tuning.
      
         - Also on the same platform, PCI I/O space was set up incorrectly and
           could not work.
      
         - On the sti platform, a syntactically incorrect DT entry caused
           warnings.
      
         - The newly added 'gr8' platform has somewhat confusing file names,
           which we rename for consistency"
      
      * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        arm64: dts: juno: fix cluster sleep state entry latency on all SoC versions
        arm64: dts: juno: Correct PCI IO window
        ARM: dts: STiH407-family: fix i2c nodes
        ARM: gr8: Rename the DTSI and relevant DTS
      8dc0f265