When a filter is used for perf top, its hists->nr_non_filtered_entries
was not updated after it removed an entry in hists__decay_entries().
Also hists->stats.total_non_filtered_period was missed too.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1398327843-31845-8-git-send-email-namhyung@kernel.orgSigned-off-by: NJiri Olsa <jolsa@kernel.org>

Currently, accounting each sample is done in multiple places - once
when adding them to the input tree, other when adding them to the
output tree.  It's not only confusing but also can cause a subtle
problem since concurrent processing like in perf top might see the
updated stats before adding entries into the output tree - like seeing
more (blank) lines at the end and/or slight inaccurate percentage.

To fix this, only account the entries when it's moved into the output
tree so that they cannot be seen prematurely.  There're some
exceptional cases here and there - they should be addressed separately
with comments.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1398327843-31845-7-git-send-email-namhyung@kernel.orgSigned-off-by: NJiri Olsa <jolsa@kernel.org>

When a filter is applied a hist entry checks whether its callchain was
folded and account it to the output stat.  But this is rather hacky
and only TUI-specific.  Simply fold the callchains for the entry looks
like a simpler and more generic solution IMHO.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1398327843-31845-6-git-send-email-namhyung@kernel.orgSigned-off-by: NJiri Olsa <jolsa@kernel.org>

Add hists__{reset,inc}_[filter_]stats() functions to cleanup accesses
to hist stats (for output).  Note that number of samples in the stat
is not handled here since it belongs to the input stage.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1398327843-31845-5-git-send-email-namhyung@kernel.orgSigned-off-by: NJiri Olsa <jolsa@kernel.org>

It's not the part of logic of hists__inc_stats() so it'd be better to
move it out of the function.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1398327843-31845-4-git-send-email-namhyung@kernel.orgSigned-off-by: NJiri Olsa <jolsa@kernel.org>

The existing hists__inc_nr_entries() is a misnomer as it's not only
increasing ->nr_entries but also other stats.  So rename it to more
general hists__inc_stats().
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1398327843-31845-3-git-send-email-namhyung@kernel.orgSigned-off-by: NJiri Olsa <jolsa@kernel.org>

This takes the parse_callchain_opt function and copies it into the
callchain.c file.  Now the c2c tool can use it too without duplicating.

Update perf-report to use the new routine too.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Reviewed-by: NNamhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1396896924-129847-5-git-send-email-dzickus@redhat.com
[ Adding missing braces to multiline if condition ]
Signed-off-by: NJiri Olsa <jolsa@redhat.com>

The system's max configuration is represented by cpu/possible and
cpu/kernel_max can be huge (4096 vs. 128), so save space by keeping
smaller structures.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Reviewed-by: NNamhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1396896924-129847-3-git-send-email-dzickus@redhat.comSigned-off-by: NJiri Olsa <jolsa@redhat.com>

This patch figures out the max number of cpus and nodes that are on the
system and creates a map of cpu to node.  This allows us to provide a cpu
and quickly get the node associated with it.

It was mostly copied from builtin-kmem.c and tweaked slightly to use less memory
(use possible cpus instead of max).  It also calculates the max number of nodes.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Reviewed-by: NNamhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1396896924-129847-2-git-send-email-dzickus@redhat.com
[ Removing out label code in init_cpunode_map ]
[ Adding check for snprintf error ]
[ Removing unneeded returns ]
Signed-off-by: NJiri Olsa <jolsa@redhat.com>

After applying some patches got another shadowing error:

  CC       util/pmu.o
util/pmu.c: In function ‘pmu_alias_terms’:
util/pmu.c:287:35: error: declaration of ‘clone’ shadows a global declaration [-Werror=shadow]

Renaming clone to cloned.
Acked-by: NDavid Ahern <dsahern@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1397674818-27054-1-git-send-email-jolsa@redhat.comSigned-off-by: NJiri Olsa <jolsa@redhat.com>

Now perf report will show absolute percentage on filter entries by
default.
Suggested-by: NJiri Olsa <jolsa@redhat.com>
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1397145720-8063-8-git-send-email-namhyung@kernel.orgSigned-off-by: NJiri Olsa <jolsa@redhat.com>

Add hist.percentage option for setting default value of the
symbol_conf.filter_relative.  It affects the output of various perf
commands (like perf report, top and diff) only if filter(s) applied.

An user can write .perfconfig file like below to show absolute
percentage of filtered entries by default:

  $ cat ~/.perfconfig
  [hist]
  percentage = absolute

And it can be changed through command line:

  $ perf report --percentage relative
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1397145720-8063-6-git-send-email-namhyung@kernel.orgSigned-off-by: NJiri Olsa <jolsa@redhat.com>

The --percentage option is for controlling overhead percentage
displayed.  It can only receive either of "relative" or "absolute".
Move the parser callback function into a common location since it's
used by multiple commands now.

For more information, please see previous commit same thing done to
"perf report".
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1397145720-8063-4-git-send-email-namhyung@kernel.orgSigned-off-by: NJiri Olsa <jolsa@redhat.com>

The --percentage option is for controlling overhead percentage
displayed.  It can only receive either of "relative" or "absolute".

"relative" means it's relative to filtered entries only so that the
sum of shown entries will be always 100%.  "absolute" means it retains
the original value before and after the filter is applied.

  $ perf report -s comm
  # Overhead       Command
  # ........  ............
  #
      74.19%           cc1
       7.61%           gcc
       6.11%            as
       4.35%            sh
       4.14%          make
       1.13%        fixdep
  ...

  $ perf report -s comm -c cc1,gcc --percentage absolute
  # Overhead       Command
  # ........  ............
  #
      74.19%           cc1
       7.61%           gcc

  $ perf report -s comm -c cc1,gcc --percentage relative
  # Overhead       Command
  # ........  ............
  #
      90.69%           cc1
       9.31%           gcc

Note that it has zero effect if no filter was applied.
Suggested-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1397145720-8063-3-git-send-email-namhyung@kernel.orgSigned-off-by: NJiri Olsa <jolsa@redhat.com>

When filtering by thread, dso or symbol on TUI it also update total
period so that the output shows different result than no filter - the
percentage changed to relative to filtered entries only.  Sometimes
this is not desired since users might expect same results with filter.

So new filtered_* fields to hists->stats to count them separately.
They'll be controlled/used by user later.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1397145720-8063-2-git-send-email-namhyung@kernel.orgSigned-off-by: NJiri Olsa <jolsa@redhat.com>

The dwarf_getcfi() only checks .debug_frame section for CFI, but as
most binaries only have .eh_frame it'd return NULL and it makes
some variables inaccessible.

Using dwarf_getcfi_elf (along with dwarf_getelf()) allows to show and
add probe to more variables.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Link: http://lkml.kernel.org/r/1396854348-9296-1-git-send-email-namhyung@kernel.orgSigned-off-by: NJiri Olsa <jolsa@redhat.com>

As Namhyung reported(https://lkml.org/lkml/2014/4/1/89),
current perf-probe -L option doesn't handle errors in line-range
searching correctly. It causes a SEGV if an error occured in the
line-range searching.

  ----
  $ perf probe -x ./perf -v -L map__load
  Open Debuginfo file: /home/namhyung/project/linux/tools/perf/perf
  fname: util/map.c, lineno:153
  New line range: 153 to 2147483647
  path: (null)
  Segmentation fault (core dumped)
  ----

This is because line_range_inline_cb() ignores errors
from find_line_range_by_line() which means that lr->path is
already freed on the error path in find_line_range_by_line().
As a result, get_real_path() accesses the lr->path and it
causes a NULL pointer exception.

This fixes line_range_inline_cb() to handle the error correctly,
and report it to the caller.

Anyway, this just fixes a possible SEGV bug, Namhyung's patch
is also required.
Reported-by: NNamhyung Kim <namhyung@kernel.org>
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20140402054831.19080.27006.stgit@ltc230.yrl.intra.hitachi.co.jpSigned-off-by: NJiri Olsa <jolsa@redhat.com>

The commit 5a62257a ("perf probe: Replace line_list with
intlist") replaced line_list to intlist but it has a problem that if a
same line was added again, it'd return -EEXIST rather than 1.

Since line_range_walk_cb() only checks the result being negative, it
resulted in failure or segfault sometimes.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Link: http://lkml.kernel.org/r/1396327677-3657-1-git-send-email-namhyung@kernel.orgSigned-off-by: NJiri Olsa <jolsa@redhat.com>

Moreover, the corresponding function in include/linux/kernel.h is marked
obsolete.
Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1395176715-4465-1-git-send-email-artagnon@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

perf_event_open() was renamed to sys_perf_event_open(); update the debug
messages to reflect this.
Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1395169842-1399-1-git-send-email-artagnon@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Because it's not used any more.
Signed-off-by: NJiri Olsa <jolsa@redhat.com>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@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/1395154016-26709-3-git-send-email-jolsa@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

So that when showing multiple events annotations, we can figure out
which is which:

  # perf record -a -e instructions,cycles sleep 1
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.826 MB perf.data (~36078 samples) ]
  # perf evlist
  instructions
  cycles
  # perf annotate intel_idle 2> /dev/null | head -1
   Percent |	Source code & Disassembly of vmlinux for instructions
  #

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-n1r51l329434js84qtb2c6l9@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Checking default guest machine should be done before allocating event
structures otherwise it'll leak memory.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Joe Mario <jmario@redhat.com>
Link: http://lkml.kernel.org/r/87ob15tx6a.fsf@sejong.aot.lge.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Now that we can properly synthesize threads system-wide, make sure the
mmap and mmap2 events use tids instead of pids to locate their maps.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1393429527-167840-3-git-send-email-dzickus@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

I.e. don't drop al->filtered entries, create the hist_entries and use
its ->filtered bitmap, that is kept with the same semantics for its
bitmap, leaving the filtering to be done at the hist_entry level, i.e.
in the UIs.

This will allow zooming in/out the filters.
Signed-off-by: NNamhyung Kim <namhyung.kim@lge.com>
Acked-by: NJiri Olsa <jolsa@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-xeyhkepu7plw716lrtb0zlnu@git.kernel.org
[ yanked this out of a previous patch ]
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Instead of bailing out as soon as we find a filter that applies, go on
checking all of them so that we can zoom in/out filters.

We also need to make sure we only update al->filtered after
thread__find_addr_map(), because there is where al->filtered gets
initialized to zero.

This will increase the cost of processing when all we don't need this
toggling, but will provide flexibility for the TUI and GTK+ interfaces,
that will incur in creating the hist_entries just once.
Signed-off-by: NNamhyung Kim <namhyung.kim@lge.com>
Acked-by: NJiri Olsa <jolsa@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-fhv9lhzdjxgp9w3w3668lsfw@git.kernel.org
[ yanked this out of a previous patch ]
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

By turning the addr_location->filtered member from a boolean to a u8
bitmap, reusing (and extending) the hist_filter enum for that.

This patch doesn't change the logic at all, as it keeps the meaning of
al->filtered !0 to mean that the entry _was_ filtered, so no change in
how this value is interpreted needs to be done at this point.

This will be soon used in upcoming patches.
Signed-off-by: NNamhyung Kim <namhyung.kim@lge.com>
Acked-by: NJiri Olsa <jolsa@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-89hmfgtr9t22sky1lyg7nw7l@git.kernel.org
[ yanked this out of a previous patch ]
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Forcing the code to always search thread by pid/tid pair.

The PID value will be needed in future to determine the process thread
leader for map groups sharing.
Signed-off-by: NJiri Olsa <jolsa@redhat.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@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/1394805606-25883-3-git-send-email-jolsa@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

When trying to capture perf data on a system running spejbb2013, perf
hung for about 15 minutes.  This is because it took that long to gather
about 10,000 thread maps and process them.

I don't think a user wants to wait that long.

Instead, recognize that thread maps are roughly equivalent to pid maps
and just quickly copy those instead.

To do this, I synthesize 'fork' events, this eventually calls
thread__fork() and copies the maps over.

The overhead goes from 15 minutes down to about a few seconds.

--
V2: based on Jiri's comments, moved malloc up a level
    and made sure the memory was freed
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Acked-by: NJiri Olsa <jolsa@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Joe Mario <jmario@redhat.com>
Link: http://lkml.kernel.org/r/1394808224-113774-1-git-send-email-dzickus@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Introduce

  $ perf kvm --list-cmds

to dump a raw list of commands for use by the completion script. In
order to do this, introduce parse_options_subcommand() for handling
subcommands as a special case in the parse-options machinery.
Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com>
Acked-by: NDavid Ahern <dsahern@gmail.com>
Acked-by: NJiri Olsa <jolsa@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Link: http://lkml.kernel.org/r/1393896396-10427-1-git-send-email-artagnon@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Those functions need evsel to investigate event group and it's passed
via hpp->ptr.  However as it can be missed easily so it's better to
pass it via an argument IMHO.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1394437440-11609-2-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Its one level up thread__find_addr_location, where it will look in
different domains for a sample: user, kernel, hypervisor, etc.

Will soon be used by a patchkit by Andi Kleen.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-so6nxkh7xj48bc5kq4jpj991@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

When printing the raw dump of a data file, the header.misc is
printed as a decimal.  Unfortunately, that field is a bit mask, so
it is hard to interpret as a decimal.

Print in hex, so the user can easily see what bits are set and more
importantly what type of info it is conveying.

V2: add 0x in front per Jiri Olsa
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1393386227-149412-3-git-send-email-dzickus@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

The __hpp__color_fmt used in the TUI code can be replace by the generic
code with small change in print_fn callback.  And it also needs to move
callback function to the generic __hpp__fmt().

No functional changes intended.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1393809254-4480-5-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Instead of the pointer to buffer and its size so that it can also get
private argument passed along with hpp.

This is a preparation of further change.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1393809254-4480-4-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

The __hpp__color_fmt used in the gtk code can be replace by the generic
code with small change in print_fn callback.

This is a preparation to upcoming changes and no functional changes
intended.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Acked-by: NPekka Enberg <penberg@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1393809254-4480-3-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Currently if a process creates a bunch of threads using pthread_create
and then perf is run in system_wide mode, the mmaps for those threads
are not captured with a synthesized mmap event.

The reason is those threads are not visible when walking the /proc/
directory looking for /proc/<pid>/maps files.  Instead they are
discovered using the /proc/<pid>/tasks file (which the synthesized comm
event uses).

This causes problems when a program is trying to map a data address to a
tid.  Because the tid has no maps, the event is dropped.  Changing the
program to look up using the pid instead of the tid, finds the correct
maps but creates ugly hacks in the program to carry the correct tid
around.

Fix this by moving the walking of the /proc/<pid>/tasks up a level (out
of the comm function) based on Arnaldo's suggestion.

Tweaked things a bit to special case the 'full' bit and 'guest' check.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1393429527-167840-2-git-send-email-dzickus@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

User space callchains and user space stack dump were disabled
for function trace event. Mailing list discussions:

  http://marc.info/?t=139302086500001&r=1&w=2
  http://marc.info/?t=139301437300003&r=1&w=2

Catching up with perf and disabling user space callchains and
DWARF unwind (uses user stack dump) for function trace event.

Adding following warnings when callchains are used
for function trace event:

  # perf record -g -e ftrace:function ...
  Disabling user space callchains for function trace event.
  ...

  # ./perf record --call-graph=dwarf -e ftrace:function ...
  Cannot use DWARF unwind for function trace event, falling back to framepointers.
  Disabling user space callchains for function trace event.
  ...
Signed-off-by: NJiri Olsa <jolsa@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1393775800-13524-4-git-send-email-jolsa@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

When trying to map a bunch of instruction addresses to their respective
threads, I kept getting a lot of bogus entries [I forget the exact
reason as I patched my code months ago].

Looking through ip__resolve_ams, I noticed the check for

  if (al.sym)

and realized, most times I have an al.map definition but sometimes an
al.sym is undefined.  In the cases where al.sym is undefined, the loop
keeps going even though a valid al.map exists.

Modify this check to use the more reliable al.map.  This fixed my bogus
entries.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1393386227-149412-2-git-send-email-dzickus@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Fixing crash in elf_section_by_name function caused by missing section
name in elf binary.
Reported-by: NAlbert Strasheim <albert@cloudflare.com>
Signed-off-by: NJiri Olsa <jolsa@redhat.com>
Cc: Albert Strasheim <albert@cloudflare.com>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
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/1393767127-599-1-git-send-email-jolsa@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>