linux-toradex.git/tools/perf, branch v4.14-rc4

Merge tag 'perf-urgent-for-mingo-4.14-20170928' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent

2017-09-29T17:31:46+00:00

Pull perf/urgent fixes from Arnaldo Carvalho de Melo:

- Fix syscalltbl build failure (Akemi Yagi)

- Fix attr.exclude_kernel setting for default cycles:p, this time for
  !root with kernel.perf_event_paranoid = -1 (Arnaldo Carvalho de Melo)

- Sync kernel ABI headers with tooling headers (Ingo Molnar)

- Remove misleading debug messages with --call-graph option (Mengting Zhang)

- Revert vmlinux symbol resolution patches for s390x (Thomas Richter)

Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Ingo Molnar

perf test: Fix vmlinux failure on s390x part 2

2017-09-28T16:01:42+00:00

On s390x perf test 1 failed. It turned out that commit cf6383f73cf2
("perf report: Fix kernel symbol adjustment for s390x") was incorrect.

The previous implementation in dso__load_sym() is also suitable for
s390x.

Therefore this patch undoes commit cf6383f73cf2

Signed-off-by: Thomas-Mich Richter 
Cc: Zvonko Kosic 
Cc: Hendrik Brueckner 
Fixes: cf6383f73cf2 ("perf report: Fix kernel symbol adjustment for s390x")
LPU-Reference: 20170915071404.58398-2-tmricht@linux.vnet.ibm.com
Link: http://lkml.kernel.org/n/tip-v101o8k25vuja2ogosgf15yy@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf test: Fix vmlinux failure on s390x

2017-09-28T16:01:42+00:00

On s390x perf test 1 failed. It turned out that commit 4a084ecfc821
("perf report: Fix module symbol adjustment for s390x") was incorrect.
The previous implementation in dso__load_sym() is also suitable for
s390x.

Therefore this patch undoes commit 4a084ecfc821.

Signed-off-by: Thomas-Mich Richter 
Cc: Hendrik Brueckner 
Cc: Zvonko Kosic 
Fixes: 4a084ecfc821 ("perf report: Fix module symbol adjustment for s390x")
LPU-Reference: 20170915071404.58398-1-tmricht@linux.vnet.ibm.com
Link: http://lkml.kernel.org/n/tip-5ani7ly57zji7s0hmzkx416l@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Fix syscalltbl build failure

2017-09-25T15:21:05+00:00

The build of kernel v4.14-rc1 for i686 fails on RHEL 6 with the error
in tools/perf:

  util/syscalltbl.c:157: error: expected ';', ',' or ')' before '__maybe_unused'
  mv: cannot stat `util/.syscalltbl.o.tmp': No such file or directory

Fix it by placing/moving:

  #include 

  outside of #ifdef HAVE_SYSCALL_TABLE block.

Signed-off-by: Akemi Yagi 
Cc: Alan Bartlett 
Link: http://lkml.kernel.org/r/oq41r8$1v9$1@blaine.gmane.org
Signed-off-by: Arnaldo Carvalho de Melo

perf report: Fix debug messages with --call-graph option

2017-09-25T15:20:12+00:00

With --call-graph option, perf report can display call chains using
type, min percent threshold, optional print limit and order. And the
default call-graph parameter is 'graph,0.5,caller,function,percent'.

Before this patch, 'perf report --call-graph' shows incorrect debug
messages as below:

  # perf report --call-graph
  Invalid callchain mode: 0.5
  Invalid callchain order: 0.5
  Invalid callchain sort key: 0.5
  Invalid callchain config key: 0.5
  Invalid callchain mode: caller
  Invalid callchain mode: function
  Invalid callchain order: function
  Invalid callchain mode: percent
  Invalid callchain order: percent
  Invalid callchain sort key: percent

That is because in function __parse_callchain_report_opt(),each field of
the call-graph parameter is passed to parse_callchain_{mode,order,
sort_key,value} in turn until it meets the matching value.

For example, the order field "caller" is passed to
parse_callchain_mode() firstly and obviously it doesn't match any mode
field. Therefore parse_callchain_mode() will shows the debug message
"Invalid callchain mode: caller", which could confuse users.

The patch fixes this issue by moving the warning out of the function
parse_callchain_{mode,order,sort_key,value}.

Signed-off-by: Mengting Zhang 
Acked-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Krister Johansen 
Cc: Li Bin 
Cc: Milian Wolff 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Cc: Yao Jin 
Link: http://lkml.kernel.org/r/1506154694-39691-1-git-send-email-zhangmengting@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo

perf evsel: Fix attr.exclude_kernel setting for default cycles:p

2017-09-25T13:39:45+00:00

Yet another fix for probing the max attr.precise_ip setting: it is not
enough settting attr.exclude_kernel for !root users, as they _can_
profile the kernel if the kernel.perf_event_paranoid sysctl is set to
-1, so check that as well.

Testing it:

As non root:

  $ sysctl kernel.perf_event_paranoid
  kernel.perf_event_paranoid = 2
  $ perf record sleep 1
  $ perf evlist -v
  cycles:uppp: ..., exclude_kernel: 1, ... precise_ip: 3, ...

Now as non-root, but with kernel.perf_event_paranoid set set to the
most permissive value, -1:

  $ sysctl kernel.perf_event_paranoid
  kernel.perf_event_paranoid = -1
  $ perf record sleep 1
  $ perf evlist -v
  cycles:ppp: ..., exclude_kernel: 0, ... precise_ip: 3, ...
  $

I.e. non-root, default kernel.perf_event_paranoid: :uppp modifier = not allowed to sample the kernel,
     non-root, most permissible kernel.perf_event_paranoid: :ppp = allowed to sample the kernel.

In both cases, use the highest available precision: attr.precise_ip = 3.

Reported-and-Tested-by: Ingo Molnar 
Cc: Adrian Hunter 
Cc: Andy Lutomirski 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Fixes: d37a36979077 ("perf evsel: Fix attr.exclude_kernel setting for default cycles:p")
Link: http://lkml.kernel.org/n/tip-nj2qkf75xsd6pw6hhjzfqqdx@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Get all of tools/{arch,include}/ in the MANIFEST

2017-09-25T13:39:43+00:00

Now that I'm switching the container builds from using a local volume
pointing to the kernel repository with the perf sources, instead getting
a detached tarball to be able to use a container cluster, some places
broke because I forgot to put some of the required files in
tools/perf/MANIFEST, namely some bitsperlong.h files.

So, to fix it do the same as for tools/build/ and pack the whole
tools/arch/ directory.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-wmenpjfjsobwdnfde30qqncj@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

mm: treewide: remove GFP_TEMPORARY allocation flag

2017-09-14T01:53:16+00:00

GFP_TEMPORARY was introduced by commit e12ba74d8ff3 ("Group short-lived
and reclaimable kernel allocations") along with __GFP_RECLAIMABLE.  It's
primary motivation was to allow users to tell that an allocation is
short lived and so the allocator can try to place such allocations close
together and prevent long term fragmentation.  As much as this sounds
like a reasonable semantic it becomes much less clear when to use the
highlevel GFP_TEMPORARY allocation flag.  How long is temporary? Can the
context holding that memory sleep? Can it take locks? It seems there is
no good answer for those questions.

The current implementation of GFP_TEMPORARY is basically GFP_KERNEL |
__GFP_RECLAIMABLE which in itself is tricky because basically none of
the existing caller provide a way to reclaim the allocated memory.  So
this is rather misleading and hard to evaluate for any benefits.

I have checked some random users and none of them has added the flag
with a specific justification.  I suspect most of them just copied from
other existing users and others just thought it might be a good idea to
use without any measuring.  This suggests that GFP_TEMPORARY just
motivates for cargo cult usage without any reasoning.

I believe that our gfp flags are quite complex already and especially
those with highlevel semantic should be clearly defined to prevent from
confusion and abuse.  Therefore I propose dropping GFP_TEMPORARY and
replace all existing users to simply use GFP_KERNEL.  Please note that
SLAB users with shrinkers will still get __GFP_RECLAIMABLE heuristic and
so they will be placed properly for memory fragmentation prevention.

I can see reasons we might want some gfp flag to reflect shorterm
allocations but I propose starting from a clear semantic definition and
only then add users with proper justification.

This was been brought up before LSF this year by Matthew [1] and it
turned out that GFP_TEMPORARY really doesn't have a clear semantic.  It
seems to be a heuristic without any measured advantage for most (if not
all) its current users.  The follow up discussion has revealed that
opinions on what might be temporary allocation differ a lot between
developers.  So rather than trying to tweak existing users into a
semantic which they haven't expected I propose to simply remove the flag
and start from scratch if we really need a semantic for short term
allocations.

[1] http://lkml.kernel.org/r/20170118054945.GD18349@bombadil.infradead.org

[akpm@linux-foundation.org: fix typo]
[akpm@linux-foundation.org: coding-style fixes]
[sfr@canb.auug.org.au: drm/i915: fix up]
  Link: http://lkml.kernel.org/r/20170816144703.378d4f4d@canb.auug.org.au
Link: http://lkml.kernel.org/r/20170728091904.14627-1-mhocko@kernel.org
Signed-off-by: Michal Hocko 
Signed-off-by: Stephen Rothwell 
Acked-by: Mel Gorman 
Acked-by: Vlastimil Babka 
Cc: Matthew Wilcox 
Cc: Neil Brown 
Cc: "Theodore Ts'o" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge tag 'perf-urgent-for-mingo-4.14-20170912' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent

2017-09-13T07:25:10+00:00

Pull perf/urgent fixes from Arnaldo Carvalho de Melo:

- Fix TUI progress bar when delta from new total from that of the
  previous update is greater than the progress "step" (screen width
  progress bar block))  (Jiri Olsa)

- Make tools/lib/api make DEBUG=1 build use -D_FORTIFY_SOURCE=2 not
  to cripple debuginfo, just like tools/perf/ does (Jiri Olsa)

- Avoid leaking the 'perf.data' file to workloads started from the
  'perf record' command line by using the O_CLOEXEC open flag (Jiri Olsa)

- Fix building when libunwind's 'unwind.h' file is present in the
  include path, clashing with tools/perf/util/unwind.h (Milian Wolff)

- Check per .perfconfig section entry flag, not just per section (Taeung Song)

- Support running perf binaries with a dash in their name, needed to
  run perf as an AppImage (Milian Wolff)

- Wait for the right child by using waitpid() when running workloads
  from 'perf stat', also to fix using perf as an AppImage (Milian Wolff)

Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Ingo Molnar

Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2017-09-12T18:28:13+00:00

Pull perf tooling updates from Ingo Molnar:
 "Perf tooling updates and fixes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf annotate browser: Help for cycling thru hottest instructions with TAB/shift+TAB
  perf stat: Only auto-merge events that are PMU aliases
  perf test: Add test case for PERF_SAMPLE_PHYS_ADDR
  perf script: Support physical address
  perf mem: Support physical address
  perf sort: Add sort option for physical address
  perf tools: Support new sample type for physical address
  perf vendor events powerpc: Remove duplicate events
  perf intel-pt: Fix syntax in documentation of config option
  perf test powerpc: Fix 'Object code reading' test
  perf trace: Support syscall name globbing
  perf syscalltbl: Support glob matching on syscall names
  perf report: Calculate the average cycles of iterations