<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/tools/perf/util/machine.h, branch linux-4.3.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.3.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.3.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2015-07-24T01:51:13Z</updated>
<entry>
<title>perf tools: Add new PERF_RECORD_SWITCH event</title>
<updated>2015-07-24T01:51:13Z</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2015-07-21T09:44:03Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0286039f777ec0b6684868c34f7b16f97a069d6e'/>
<id>urn:sha1:0286039f777ec0b6684868c34f7b16f97a069d6e</id>
<content type='text'>
Support processing of PERF_RECORD_SWITCH events and
PERF_RECORD_SWITCH_CPU_WIDE events. There is a single
tools callback for them both so that the tool must
check the event type before using the extra members
in PERF_RECORD_SWITCH_CPU_WIDE.

There is still no way to select the events, though.
That is added in a subsequest patch.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Acked-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Tested-by: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Andi Kleen &lt;ak@linux.intel.com&gt;
Cc: Mathieu Poirier &lt;mathieu.poirier@linaro.org&gt;
Cc: Pawel Moll &lt;pawel.moll@arm.com&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
Link: http://lkml.kernel.org/r/1437471846-26995-3-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf symbols: Provide libtraceevent callback to resolve kernel symbols</title>
<updated>2015-07-24T01:01:37Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2015-07-22T19:14:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c3168b0db93ad5ffeede4ecdf807dab64270f55d'/>
<id>urn:sha1:c3168b0db93ad5ffeede4ecdf807dab64270f55d</id>
<content type='text'>
That provides the function signature expected by libtraceevent's
pevent_set_function_resolver().

Acked-by: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Borislav Petkov &lt;bp@suse.de&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Link: http://lkml.kernel.org/n/tip-ie6hvlb6u15y4ulg9j1612zg@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf tools: Configurable per thread proc map processing time out</title>
<updated>2015-06-19T21:27:13Z</updated>
<author>
<name>Kan Liang</name>
<email>kan.liang@intel.com</email>
</author>
<published>2015-06-17T13:51:11Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9d9cad763ca79dd3697e9f2d1df648e37496582b'/>
<id>urn:sha1:9d9cad763ca79dd3697e9f2d1df648e37496582b</id>
<content type='text'>
The time out to limit the individual proc map processing was hard code
to 500ms. This patch introduce a new option --proc-map-timeout to make
the time limit configurable.

Signed-off-by: Kan Liang &lt;kan.liang@intel.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Ying Huang &lt;ying.huang@intel.com&gt;
Link: http://lkml.kernel.org/r/1434549071-25611-2-git-send-email-kan.liang@intel.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf tools: Ensure thread-stack is flushed</title>
<updated>2015-06-19T19:03:33Z</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2015-05-29T13:33:30Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a5499b37197ab4b5fed101370df7ccadacbb4340'/>
<id>urn:sha1:a5499b37197ab4b5fed101370df7ccadacbb4340</id>
<content type='text'>
The thread-stack represents a thread's current stack.  When a thread
exits there can still be many functions on the stack e.g. exit() can be
called many levels deep, so all the callers will never return.  To get
that information output, the thread-stack must be flushed.

Previously it was assumed the thread-stack would be flushed when the
struct thread was deleted.  With thread ref-counting it is no longer
clear when that will be, if ever. So instead explicitly flush all the
thread-stacks at the end of a session.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Link: http://lkml.kernel.org/r/1432906425-9911-3-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf machine: Fix up some more method names</title>
<updated>2015-06-08T13:31:34Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2015-06-01T15:01:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9f2de31542f1ac38a15117f90ee6b8449951d86e'/>
<id>urn:sha1:9f2de31542f1ac38a15117f90ee6b8449951d86e</id>
<content type='text'>
Calling the function 'machine__new_module' implies a new 'module' will
be allocated, when in fact what is returned is a 'struct map' instance,
that not necessarily will be instantiated, as if one already exists with
the given module name, it will be returned instead.

So be consistent with other "find and if not there, create" like
functions, like machine__findnew_thread, machine__findnew_dso, etc, and
rename it to machine__findnew_module_map(), that in turn will call
machine__findnew_module_dso().

Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Link: http://lkml.kernel.org/n/tip-acv830vd3hwww2ih5vjtbmu3@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf tools: handle PERF_RECORD_LOST_SAMPLES</title>
<updated>2015-06-07T14:09:06Z</updated>
<author>
<name>Kan Liang</name>
<email>kan.liang@intel.com</email>
</author>
<published>2015-05-10T19:13:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c4937a91ea56b546234b0608a413ebad90536d26'/>
<id>urn:sha1:c4937a91ea56b546234b0608a413ebad90536d26</id>
<content type='text'>
This patch modifies the perf tool to handle the new RECORD type,
PERF_RECORD_LOST_SAMPLES.

The number of lost-sample events is stored in
.nr_events[PERF_RECORD_LOST_SAMPLES]. The exact number of samples
which the kernel dropped is stored in total_lost_samples.

When the percentage of dropped samples is greater than 5%, a warning
is printed.

Here are some examples:

Eg 1, Recording different frequently-occurring events is safe with the
      patch. Only a very low drop rate is associated with such actions.

$ perf record -e '{cycles:p,instructions:p}' -c 20003 --no-time ~/tchain ~/tchain

$ perf report -D | tail
          SAMPLE events:     120243
           MMAP2 events:          5
    LOST_SAMPLES events:         24
  FINISHED_ROUND events:         15
cycles:p stats:
           TOTAL events:      59348
          SAMPLE events:      59348
instructions:p stats:
           TOTAL events:      60895
          SAMPLE events:      60895

$ perf report --stdio --group
 # To display the perf.data header info, please use --header/--header-only options.
 #
 #
 # Total Lost Samples: 24
 #
 # Samples: 120K of event 'anon group { cycles:p, instructions:p }'
 # Event count (approx.): 24048600000
 #
 #         Overhead  Command      Shared Object     Symbol
 # ................  ...........  ................
 ..................................
 #
    99.74%  99.86%  tchain_edit  tchain_edit       [.] f3
     0.09%   0.02%  tchain_edit  tchain_edit       [.] f2
     0.04%   0.00%  tchain_edit  [kernel.vmlinux]  [k] ixgbe_read_reg

Eg 2, Recording the same thing multiple times can lead to high drop
      rate, but it is not a useful configuration.

$ perf record -e '{cycles:p,cycles:p}' -c 20003 --no-time ~/tchain
Warning: Processed 600592 samples and lost 99.73% samples!
[perf record: Woken up 148 times to write data]
[perf record: Captured and wrote 36.922 MB perf.data (1206322 samples)]
[perf record: Woken up 1 times to write data]
[perf record: Captured and wrote 0.121 MB perf.data (1629 samples)]

Signed-off-by: Kan Liang &lt;kan.liang@intel.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: acme@infradead.org
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1431285195-14269-9-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf machine: Introduce machine__findnew_dso() method</title>
<updated>2015-05-29T15:43:44Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2015-05-29T14:31:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=aa7cc2ae5ae69aff555793fbfcff514141bb23f3'/>
<id>urn:sha1:aa7cc2ae5ae69aff555793fbfcff514141bb23f3</id>
<content type='text'>
Similar to machine__findnew_thread(), also prepping for refcounting and
locking, this time for struct dso instances.

Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Link: http://lkml.kernel.org/n/tip-fv3tshv5o1413coh147lszjc@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf machine: No need to have two DSOs lists</title>
<updated>2015-05-29T15:43:43Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2015-05-28T16:06:42Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3d39ac538629e4f00a6e1c38d46346f1b8e69505'/>
<id>urn:sha1:3d39ac538629e4f00a6e1c38d46346f1b8e69505</id>
<content type='text'>
We can, given a DSO, figure out if it is a kernel, a kernel module or
a userlevel DSO, so stop having to process two lists in several
functions.

If searching becomes an issue at some point, we can have them in a
rbtree, etc.

Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Borislav Petkov &lt;bp@suse.de&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Don Zickus &lt;dzickus@redhat.com&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
Link: http://lkml.kernel.org/n/tip-s4yb0onpdywu6dj2xl9lxi4t@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf machine: Protect the machine-&gt;threads with a rwlock</title>
<updated>2015-05-08T19:19:27Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2015-04-06T23:43:22Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b91fc39f4ad7503419dd617df78401fa36266cb3'/>
<id>urn:sha1:b91fc39f4ad7503419dd617df78401fa36266cb3</id>
<content type='text'>
In addition to using refcounts for the struct thread lifetime
management, we need to protect access to machine-&gt;threads from
concurrent access.

That happens in 'perf top', where a thread processes events, inserting
and deleting entries from that rb_tree while another thread decays
hist_entries, that end up dropping references and ultimately deleting
threads from the rb_tree and releasing its resources when no further
hist_entry (or other data structures, like in 'perf sched') references
it.

So the rule is the same for refcounts + protected trees in the kernel,
get the tree lock, find object, bump the refcount, drop the tree lock,
return, use object, drop the refcount if no more use of it is needed,
keep it if storing it in some other data structure, drop when releasing
that data structure.

I.e. pair "t = machine__find(new)_thread()" with a "thread__put(t)", and
"perf_event__preprocess_sample(&amp;al)" with "addr_location__put(&amp;al)".

The addr_location__put() one is because as we return references to
several data structures, we may end up adding more reference counting
for the other data structures and then we'll drop it at
addr_location__put() time.

Acked-by: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Borislav Petkov &lt;bp@suse.de&gt;
Cc: Don Zickus &lt;dzickus@redhat.com&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
Link: http://lkml.kernel.org/n/tip-bs9rt4n0jw3hi9f3zxyy3xln@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf tools: Add support for PERF_RECORD_ITRACE_START</title>
<updated>2015-05-05T21:12:58Z</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2015-04-30T14:37:30Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0ad21f6869222fd7fd7c63f02febea082e801fc2'/>
<id>urn:sha1:0ad21f6869222fd7fd7c63f02febea082e801fc2</id>
<content type='text'>
Add support for the PERF_RECORD_ITRACE_START event type.  This event can
be used to determine the pid and tid that are running when Instruction
Tracing starts.  Generally that information would come from a
sched_switch event but, at the start, no sched_switch events may yet
have been recorded.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Acked-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: David Ahern &lt;dsahern@gmail.com&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Namhyung Kim &lt;namhyung@gmail.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
Link: http://lkml.kernel.org/r/1430404667-10593-8-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
</feed>
