<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/tools, branch v3.12.10</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/tools?h=v3.12.10</id>
<link rel='self' href='https://git.amat.us/linux/atom/tools?h=v3.12.10'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-02-06T19:22:18Z</updated>
<entry>
<title>perf kvm: Fix kvm report without guestmount.</title>
<updated>2014-02-06T19:22:18Z</updated>
<author>
<name>Dongsheng Yang</name>
<email>yangds.fnst@cn.fujitsu.com</email>
</author>
<published>2013-12-20T18:41:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=26991248a1e553068c935036947ae2d66d452fb5'/>
<id>urn:sha1:26991248a1e553068c935036947ae2d66d452fb5</id>
<content type='text'>
commit ad85ace07a05062ef6b59c35a5e80b6eaee1eee6 upstream.

Currently, if we use perf kvm --guestkallsyms --guestmodules report, we
can not get the perf information from perf data file. All sample are
shown as unknown.

Reproducing steps:
	# perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules record -a sleep 1
	[ perf record: Woken up 1 times to write data ]
	[ perf record: Captured and wrote 0.624 MB perf.data.guest (~27260 samples) ]
	# perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules report |grep %
	   100.00%  [guest/6471]  [unknown]         [g] 0xffffffff8164f330

This bug was introduced by 207b57926 (perf kvm: Fix regression with guest machine creation).
In original code, it uses perf_session__find_machine(), it means we deliver symbol to machine
which has the same pid, if no machine found, deliver it to *default* guest. But if we use
perf_session__findnew_machine() here, if no machine was found, new machine with pid will be built
and added. Then the default guest which with pid == 0 will never get a symbol.

And because the new machine initialized here has no kernel map created, the symbol delivered to
it will be marked as "unknown".

This patch here is to revert commit 207b57926 and fix the SEGFAULT bug in another way.

Verification steps:
	# ./perf kvm --guestkallsyms /home/kallsyms --guestmodules /home/modules record -a sleep 1
	[ perf record: Woken up 1 times to write data ]
	[ perf record: Captured and wrote 0.651 MB perf.data.guest (~28437 samples) ]
	# ./perf kvm --guestkallsyms /home/kallsyms --guestmodules /home/modules report |grep %
	    22.64%    :6471  [guest.kernel.kallsyms]  [g] update_rq_clock.part.70
	    19.99%    :6471  [guest.kernel.kallsyms]  [g] d_free
	    18.46%    :6471  [guest.kernel.kallsyms]  [g] bio_phys_segments
	    16.25%    :6471  [guest.kernel.kallsyms]  [g] dequeue_task
	    12.78%    :6471  [guest.kernel.kallsyms]  [g] __switch_to
	     7.91%    :6471  [guest.kernel.kallsyms]  [g] scheduler_tick
	     1.75%    :6471  [guest.kernel.kallsyms]  [g] native_apic_mem_write
	     0.21%    :6471  [guest.kernel.kallsyms]  [g] apic_timer_interrupt

Signed-off-by: Dongsheng Yang &lt;yangds.fnst@cn.fujitsu.com&gt;
Acked-by: David Ahern &lt;dsahern@gmail.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Link: http://lkml.kernel.org/r/1387564907-3045-1-git-send-email-yangds.fnst@cn.fujitsu.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cpupower: Fix segfault due to incorrect getopt_long arugments</title>
<updated>2014-01-09T20:25:12Z</updated>
<author>
<name>Josh Boyer</name>
<email>jwboyer@redhat.com</email>
</author>
<published>2013-10-11T12:45:51Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=123cf1180f8baf254852948ebe26f2ca54289507'/>
<id>urn:sha1:123cf1180f8baf254852948ebe26f2ca54289507</id>
<content type='text'>
commit f447ef4a56dee4b68a91460bcdfe06b5011085f2 upstream.

If a user calls 'cpupower set --perf-bias 15', the process will end with
a SIGSEGV in libc because cpupower-set passes a NULL optarg to the atoi
call.  This is because the getopt_long structure currently has all of
the options as having an optional_argument when they really have a
required argument.  We change the structure to use required_argument to
match the short options and it resolves the issue.

This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1000439

Signed-off-by: Josh Boyer &lt;jwboyer@fedoraproject.org&gt;
Cc: Dominik Brodowski &lt;linux@dominikbrodowski.net&gt;
Cc: Thomas Renninger &lt;trenn@suse.de&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>perf tools: Synthesize anon MMAP records again</title>
<updated>2013-12-04T19:05:10Z</updated>
<author>
<name>Don Zickus</name>
<email>dzickus@redhat.com</email>
</author>
<published>2013-11-13T18:32:06Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ca51a9cb5fbbec24c6fe15f4a5ff4a4c086bfcb1'/>
<id>urn:sha1:ca51a9cb5fbbec24c6fe15f4a5ff4a4c086bfcb1</id>
<content type='text'>
commit 9d4ecc8893832337daf241236841db966fa53489 upstream.

When introducing the PERF_RECORD_MMAP2 in:

5c5e854bc760 perf tools: Add attr-&gt;mmap2 support

A check for the number of entries parsed by sscanf was introduced that
assumed all of the 8 fields needed to be correctly parsed so that
particular /proc/pid/maps line would be considered synthesizable.

That broke anon records synthesizing, as it doesn't have the 'execname'
field.

Fix it by keeping the sscanf return check, changing it to not require
that the 'execname' variable be parsed, so that the preexisting logic
can kick in and set it to '//anon'.

This should get things like JIT profiling working again.

Signed-off-by: Don Zickus &lt;dzickus@redhat.com&gt;
Cc: Bill Gray &lt;bgray@redhat.com&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Joe Mario &lt;jmario@redhat.com&gt;
Cc: Richard Fowles &lt;rfowles@redhat.com&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
Link: http://lkml.kernel.org/n/tip-bo4akalno7579shpz29u867j@git.kernel.org
[ commit log message is mine, dzickus reported the problem with a patch ]
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>perf tools: Remove cast of non-variadic function to variadic</title>
<updated>2013-12-04T19:05:10Z</updated>
<author>
<name>Michael Hudson-Doyle</name>
<email>michael.hudson@linaro.org</email>
</author>
<published>2013-10-31T23:47:45Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d659ec28a6386ced8c3f4d074be0ce4d47e9fbc4'/>
<id>urn:sha1:d659ec28a6386ced8c3f4d074be0ce4d47e9fbc4</id>
<content type='text'>
commit 53805eca3d89b095062c11a6798689bb0af09216 upstream.

The 4fb71074a570 (perf ui/hist: Consolidate hpp helpers) cset introduced
a cast of percent_color_snprintf to a function pointer type with
varargs.  Change percent_color_snprintf to be variadic and remove the
cast.

The symptom of this was all percentages being reported as 0.00% in perf
report --stdio output on the armhf arch.

Signed-off-by: Michael Hudson-Doyle &lt;michael.hudson@linaro.org&gt;
Acked-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Jean Pihet &lt;jean.pihet@linaro.org&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Link: http://lkml.kernel.org/r/87zjppvw7y.fsf@canonical.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>perf tools: Fixup mmap event consumption</title>
<updated>2013-10-28T19:06:00Z</updated>
<author>
<name>Zhouyi Zhou</name>
<email>zhouzhouyi@gmail.com</email>
</author>
<published>2013-10-24T07:43:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8e50d384cc1d5afd2989cf0f7093756ed7164eb2'/>
<id>urn:sha1:8e50d384cc1d5afd2989cf0f7093756ed7164eb2</id>
<content type='text'>
The tail position of the event buffer should only be modified after
actually use that event.

If not the event buffer could be invalid before use, and segment fault
occurs when invoking perf top -G.

Signed-off-by: Zhouyi Zhou &lt;yizhouzhou@ict.ac.cn&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Zhouyi Zhou &lt;yizhouzhou@ict.ac.cn&gt;
Link: http://lkml.kernel.org/r/1382600613-32177-1-git-send-email-zhouzhouyi@gmail.com
[ Simplified the logic using exit gotos and renamed write_tail method to mmap_consume ]
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf top: Split -G and --call-graph</title>
<updated>2013-10-28T19:06:00Z</updated>
<author>
<name>Jiri Olsa</name>
<email>jolsa@redhat.com</email>
</author>
<published>2013-10-26T14:25:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ae779a630977d93fbebfa06216ea47df5b5c62c8'/>
<id>urn:sha1:ae779a630977d93fbebfa06216ea47df5b5c62c8</id>
<content type='text'>
Splitting -G and --call-graph for record command, so we could use '-G'
with no option.

The '-G' option now takes NO argument and enables the configured unwind
method, which is currently the frame pointers method.

It will be possible to configure unwind method via config file in
upcoming patches.

All current '-G' arguments is overtaken by --call-graph option.

NOTE: The documentation for top --call-graph option
      was wrongly copied from report command.

Signed-off-by: Jiri Olsa &lt;jolsa@redhat.com&gt;
Tested-by: David Ahern &lt;dsahern@gmail.com&gt;
Tested-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Reviewed-by: David Ahern &lt;dsahern@gmail.com&gt;
Acked-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: Corey Ashford &lt;cjashfor@linux.vnet.ibm.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Link: http://lkml.kernel.org/r/1382797536-32303-3-git-send-email-jolsa@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf record: Split -g and --call-graph</title>
<updated>2013-10-28T19:05:59Z</updated>
<author>
<name>Jiri Olsa</name>
<email>jolsa@redhat.com</email>
</author>
<published>2013-10-26T14:25:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=09b0fd45ff63413df94cbd832a765076b201edbb'/>
<id>urn:sha1:09b0fd45ff63413df94cbd832a765076b201edbb</id>
<content type='text'>
Splitting -g and --call-graph for record command, so we could use '-g'
with no option.

The '-g' option now takes NO argument and enables the configured unwind
method, which is currently the frame pointers method.

It will be possible to configure unwind method via config file in
upcoming patches.

All current '-g' arguments is overtaken by --call-graph option.

Signed-off-by: Jiri Olsa &lt;jolsa@redhat.com&gt;
Tested-by: David Ahern &lt;dsahern@gmail.com&gt;
Tested-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Reviewed-by: David Ahern &lt;dsahern@gmail.com&gt;
Acked-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: Corey Ashford &lt;cjashfor@linux.vnet.ibm.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Link: http://lkml.kernel.org/r/1382797536-32303-2-git-send-email-jolsa@redhat.com
[ reordered -g/--call-graph on --help and expanded the man page
  according to comments by David Ahern and Namhyung Kim ]
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf hists: Add color overhead for stdio output buffer</title>
<updated>2013-10-28T19:05:59Z</updated>
<author>
<name>Jiri Olsa</name>
<email>jolsa@redhat.com</email>
</author>
<published>2013-10-25T11:24:53Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9754c4f9b23d5ce6756514acdf134ad61470734a'/>
<id>urn:sha1:9754c4f9b23d5ce6756514acdf134ad61470734a</id>
<content type='text'>
Following commit tightened up the buffer size for output to strict width
of used format columns:

  99cf666 perf hists: Fix formatting of long symbol names

This works fine until you hit color overhead output which places extra
bytes into output buffer. We need to account for color overhead in the
output buffer. Adding maximum color byte size to the output buffer size.

Signed-off-by: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Corey Ashford &lt;cjashfor@linux.vnet.ibm.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Link: http://lkml.kernel.org/r/1382700293-1803-1-git-send-email-jolsa@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf tools: Fix up /proc/PID/maps parsing</title>
<updated>2013-10-28T12:38:12Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2013-10-28T12:38:12Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2fd869f08aec5a8e4cbf01bc3fa345c4e53342d7'/>
<id>urn:sha1:2fd869f08aec5a8e4cbf01bc3fa345c4e53342d7</id>
<content type='text'>
When introducing support for MMAP2 we considered more parts of each map
representation in /proc/PID/maps, and when disabling it we forgot to
reduce the number of expected parsed/assigned entries in the sscanf
call, fix it to expect the right number of desired fields, 5.

Reported-by: Markus Trippelsdorf &lt;markus@trippelsdorf.de&gt;
Based-on-a-patch-by: Markus Trippelsdorf &lt;markus@trippelsdorf.de&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Mike Galbraith &lt;efault@gmx.de&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
Link: http://lkml.kernel.org/n/tip-vrbo1wik997ahjzl1chm3bdm@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf script python: Fix mem leak due to missing Py_DECREFs on dict entries</title>
<updated>2013-10-24T13:16:54Z</updated>
<author>
<name>Joseph Schuchart</name>
<email>joseph.schuchart@tu-dresden.de</email>
</author>
<published>2013-10-24T13:10:51Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c0268e8d1f450e286fc55e77f53a9ede6b72acab'/>
<id>urn:sha1:c0268e8d1f450e286fc55e77f53a9ede6b72acab</id>
<content type='text'>
We are using the Python scripting interface in perf to extract kernel
events relevant for performance analysis of HPC codes. We noticed that
the "perf script" call allocates a significant amount of memory (in the
order of several 100 MiB) during it's run, e.g. 125 MiB for a 25 MiB
input file:

  $&gt; perf record -o perf.data -a -R -g fp \
       -e power:cpu_frequency -e sched:sched_switch \
       -e sched:sched_migrate_task -e sched:sched_process_exit \
       -e sched:sched_process_fork -e sched:sched_process_exec \
       -e cycles  -m 4096 --freq 4000
  $&gt; /usr/bin/time perf script -i perf.data -s dummy_script.py
  0.84user 0.13system 0:01.92elapsed 51%CPU (0avgtext+0avgdata
  125532maxresident)k
  73072inputs+0outputs (57major+33086minor)pagefaults 0swaps

Upon further investigation using the valgrind massif tool, we noticed
that Python objects that are created in trace-event-python.c via
PyString_FromString*() (and their Integer and Long counterparts) are
never free'd.

The reason for this seem to be missing Py_DECREF calls on the objects
that are returned by these functions and stored in the Python
dictionaries. The Python dictionaries do not steal references (as
opposed to Python tuples and lists) but instead add their own reference.

Hence, the reference that is returned by these object creation functions
is never released and the memory is leaked. (see [1,2])

The attached patch fixes this by wrapping all relevant calls to
PyDict_SetItemString() and decrementing the reference counter
immediately after the Python function call.

This reduces the allocated memory to a reasonable amount:

  $&gt; /usr/bin/time perf script -i perf.data -s dummy_script.py
  0.73user 0.05system 0:00.79elapsed 99%CPU (0avgtext+0avgdata
  49132maxresident)k
  0inputs+0outputs (0major+14045minor)pagefaults 0swaps

For comparison, with a 120 MiB input file the memory consumption
reported by time drops from almost 600 MiB to 146 MiB.

The patch has been tested using Linux 3.8.2 with Python 2.7.4 and Linux
3.11.6 with Python 2.7.5.

Please let me know if you need any further information.

[1] http://docs.python.org/2/c-api/tuple.html#PyTuple_SetItem
[2] http://docs.python.org/2/c-api/dict.html#PyDict_SetItemString

Signed-off-by: Joseph Schuchart &lt;joseph.schuchart@tu-dresden.de&gt;
Reviewed-by: Tom Zanussi &lt;tom.zanussi@linux.intel.com&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Cc: Tom Zanussi &lt;tom.zanussi@linux.intel.com&gt;
Link: http://lkml.kernel.org/r/1381468543-25334-4-git-send-email-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
</feed>
