Em Sun, Nov 14, 2010 at 09:03:20PM -0700, David S. Ahern escreveu:
>
> I'm trying to understand how the latest perf tools are designed with
> respect to off-line analysis.
>
> Specifically, I have a system running binaries and libraries that are
> stripped and no vmlinux is installed. For analysi
Em Tue, Nov 16, 2010 at 09:40:42PM -0200, Arnaldo Carvalho de Melo escreveu:
> [r...@felicio ~]#
>
> To fit your setup you need:
>
> . Populate your devel machine ~/.debug build-id database with the unstripped
> binaries, do that using another perf command, buildid-cache, exa
Em Wed, Nov 17, 2010 at 04:31:53PM -0700, David S. Ahern escreveu:
> On 11/16/10 16:40, Arnaldo Carvalho de Melo wrote:
> > Em Sun, Nov 14, 2010 at 09:03:20PM -0700, David S. Ahern escreveu:
> >> I've been reading the source and can't say I follow all of the build-i
Em Thu, Nov 18, 2010 at 02:54:27PM -0700, David S. Ahern escreveu:
> Hmmm From a user perspective maintaining build-id databases for
> short-use builds is more complex than using a --rootfs argument. i.e.,
> add rootfs to symbol_conf with a default value of "", add a --rootfs
> argument to anal
Em Sat, Nov 20, 2010 at 08:44:06AM -0700, David S. Ahern escreveu:
>
>
> On 11/19/10 05:50, Arnaldo Carvalho de Melo wrote:
> > Yeah, I think it is worth having it for maximum flexibility, can you try
> > to implement it and post the patch for discussion?
>
> What
Em Sun, Nov 21, 2010 at 09:17:55AM -0700, y...@cisco.com escreveu:
> From: David Ahern
>
> The rootfs argument allows analysis of perf.data file using a locally
> accessible filesystem tree with debug symbols - e.g., loop mounted
> KVM disk images, NFS, USB keys, initrds, etc. Anything with an O
Em Sun, Nov 21, 2010 at 10:02:24AM -0700, David S. Ahern escreveu:
>
>
> On 11/21/10 09:34, Arnaldo Carvalho de Melo wrote:
> > Em Sun, Nov 21, 2010 at 09:17:55AM -0700, y...@cisco.com escreveu:
> >> From: David Ahern
> >>
> >> The rootfs argument
Em Sun, Nov 21, 2010 at 08:03:50AM -0700, David Ahern escreveu:
> continue statement in default case applies when a second pass is
> wanted as well. As it stands the code drops down to the open
> re-using the value in name from the previous origin attempt.
>
> Signed-off-by: David Ahern
> ---
>
Em Sun, Nov 21, 2010 at 05:50:46PM -0700, David S. Ahern escreveu:
> On 11/21/10 15:03, Arnaldo Carvalho de Melo wrote:
> > Em Sun, Nov 21, 2010 at 08:03:50AM -0700, David Ahern escreveu:
> >> continue statement in default case applies when a second pass is
> >> wante
Em Tue, Nov 23, 2010 at 06:50:30AM +, Brian Downing escreveu:
> I am trying to run perf on a system with split debuginfo. I'm creating the
> debuginfo by:
>
> objcopy --only-keep-debug file /usr/lib/debug/path/to/file
> strip file
> objcopy --add-gnu-debuglink=/usr/lib/debug/path/to/file file
Em Tue, Nov 30, 2010 at 12:50:14PM +0100, Franck Bui-Huu escreveu:
> From: Franck Bui-Huu
>
> This primarily fixes perf-report, which didn't report the correct type
> of event if perf-record was called to record one event different from
> 'cycles':
>
> $ perf record -e instructions true
>
Adding more people to the CC, hope they can stick some Acked-by on the
final version of this patch.
Em Mon, Nov 29, 2010 at 04:07:09PM -0700, David Ahern escreveu:
> Add a timehist option to perf record to save cpu and kernel timestamp
> with each sample. Add timehist option to perf report to disp
Em Tue, Dec 07, 2010 at 07:39:46PM -0700, David Ahern escreveu:
> This is useful for analyzing a perf data file on a different system
> than the one data was collected on and still include symbols from
> loaded kernel modules in the output.
Applied and also added the relevant entry to
tools/perf/D
Em Tue, Dec 07, 2010 at 07:42:54PM -0700, David Ahern escreveu:
> The symfs argument allows analysis of perf.data file using a locally
> accessible filesystem tree with debug symbols - e.g., tree created
> during image builds, sshfs mount, loop mounted KVM disk images,
> USB keys, initrds, etc. Any
Em Tue, Dec 07, 2010 at 06:54:45PM -0700, David Ahern escreveu:
> Add a timehist option to perf record to save cpu and kernel timestamp
> with each sample.
>
> Add timehist option to perf report to display a pretty-print format
> of the timestamp, cpu, and event data each event rather than
> gener
Em Wed, Dec 08, 2010 at 03:22:37PM -0700, David S. Ahern escreveu:
> On 12/08/10 13:56, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Dec 07, 2010 at 07:42:54PM -0700, David Ahern escreveu:
> >> + if ((strlen(symbol_conf.symfs) != 0) ||
> >
Em Thu, Dec 09, 2010 at 04:00:08PM +0100, Francis Moreau escreveu:
> I'm trying to use perf-probe(1) with the latest F14 kernel
> (2.6.35.9-64.fc14.x86_64).
>
> I also installed kernel-debug-debuginfo-2.6.35.9-64.fc14.x86_64 which
> contains the running vmlinux image AFAICT.
>
> I added it to the
Em Wed, Dec 08, 2010 at 07:33:40PM -0700, David Ahern escreveu:
> The symfs argument allows analysis of perf.data file using a locally
> accessible filesystem tree with debug symbols - e.g., tree created
> during image builds, sshfs mount, loop mounted KVM disk images,
> USB keys, initrds, etc. Any
Em Tue, Dec 07, 2010 at 06:54:43PM -0700, David Ahern escreveu:
> David Ahern (2):
> perf tools: Add reference timestamp to perf header
> perf tools: Add option to show time history of event samples
>
> tools/perf/builtin-record.c |8 +++
> tools/perf/builtin-report.c | 131
> ++
Em Fri, Dec 10, 2010 at 08:30:19AM +0100, Franck Bui-Huu escreveu:
> Looks like a standard path is missing...
>
> What about adding the one above since it looks like Fedora is installing
> their debug kernel images at this place ?
Can I get your signed-off-by on this one?
- Arnaldo
> diff --gi
Em Mon, Dec 13, 2010 at 11:02:52AM +0100, Francis Moreau escreveu:
> Arnaldo Carvalho de Melo writes:
> > Em Thu, Dec 09, 2010 at 04:00:08PM +0100, Francis Moreau escreveu:
> >> I'm trying to use perf-probe(1) with the latest F14 kernel
> >> (2.6.35.9-64.fc14
Em Sun, Dec 12, 2010 at 09:16:16PM +0100, Frederic Weisbecker escreveu:
> On Tue, Dec 07, 2010 at 06:54:44PM -0700, David Ahern wrote:
> > +++ b/tools/perf/util/header.c
> > @@ -191,6 +191,40 @@ static int write_padded(int fd, const void *bf, size_t
> > count,
> > +static int perf_header__read_ref
Em Mon, Dec 13, 2010 at 02:08:56PM +0100, Francis Moreau escreveu:
> Arnaldo Carvalho de Melo writes:
> > Em Mon, Dec 13, 2010 at 11:02:52AM +0100, Francis Moreau escreveu:
> >> Arnaldo Carvalho de Melo writes:
> >> > Em Thu, Dec 09, 2010 at 04:00:08PM +0100, Franci
Em Mon, Dec 13, 2010 at 11:04:36PM +0900, Masami Hiramatsu escreveu:
> (2010/12/13 22:08), Francis Moreau wrote:
> > Arnaldo Carvalho de Melo writes:
> >
> >> Em Mon, Dec 13, 2010 at 11:02:52AM +0100, Francis Moreau escreveu:
> >>> Arnaldo Carvalho de Melo wr
Em Mon, Dec 13, 2010 at 04:11:16PM +0100, Francis Moreau escreveu:
> But as I said, there's no matching build-id. I understand that -k is
> currently broken but suppose that it works, which vmlinux should I use
> then ?
>
> $ rpm -qa | grep kernel
> kernel-debuginfo-common-x86_64-2.6.35.9-64.fc14.
Em Sun, Dec 12, 2010 at 11:15:26PM +0100, Franck Bui-Huu escreveu:
> Arnaldo Carvalho de Melo writes:
>
> > Em Fri, Dec 10, 2010 at 08:30:19AM +0100, Franck Bui-Huu escreveu:
> >> Looks like a standard path is missing...
> >>
> >> What about adding the
Em Mon, Dec 13, 2010 at 04:54:56PM +0100, Frederic Weisbecker escreveu:
> On Mon, Dec 13, 2010 at 07:39:24AM -0700, David S. Ahern wrote:
> > On 12/12/10 13:16, Frederic Weisbecker wrote:
> > >> int perf_session__create_kernel_maps(struct perf_session *self)
> > >> {
> > >> int ret = mac
Em Mon, Dec 13, 2010 at 11:15:57AM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Sun, Dec 12, 2010 at 09:16:16PM +0100, Frederic Weisbecker escreveu:
> > On Tue, Dec 07, 2010 at 06:54:44PM -0700, David Ahern wrote:
> > > +++ b/tools/perf/util/header.c
> > > @@ -
Em Mon, Dec 13, 2010 at 06:09:26PM +0100, Frederic Weisbecker escreveu:
> On Mon, Dec 13, 2010 at 02:48:54PM -0200, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Dec 13, 2010 at 04:54:56PM +0100, Frederic Weisbecker escreveu:
> > > On Mon, Dec 13, 2010 at 07:39:24AM -0700, Da
Em Mon, Dec 13, 2010 at 06:18:19PM +0100, Peter Zijlstra escreveu:
> On Mon, 2010-12-13 at 18:15 +0100, Frederic Weisbecker wrote:
> > On Mon, Dec 13, 2010 at 06:11:29PM +0100, Peter Zijlstra wrote:
> > > On Mon, 2010-12-13 at 18:09 +0100, Frederic Weisbecker wrote:
> > > > So this should be the la
Em Mon, Dec 13, 2010 at 06:35:16PM +0100, Peter Zijlstra escreveu:
> On Mon, 2010-12-13 at 15:22 -0200, Arnaldo Carvalho de Melo wrote:
> > > No, the last one already happened, you cannot postpone the last one,
> > > there will always be another excuse.
> >
> >
Em Mon, Dec 13, 2010 at 10:36:39AM -0700, David S. Ahern escreveu:
>
>
> On 12/13/10 09:48, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Dec 13, 2010 at 04:54:56PM +0100, Frederic Weisbecker escreveu:
> >> On Mon, Dec 13, 2010 at 07:39:24AM -0700, David S. Ahern wrote:
Em Mon, Dec 13, 2010 at 11:01:13AM -0700, David S. Ahern escreveu:
> On 12/13/10 10:57, Peter Zijlstra wrote:
> >> What about creating a PERF_RECORD_TIME and generate an event when the
> >> counter is opened? It contains a PERF_SAMPLE_TIME and say
> >> PERF_SAMPLE_TOD (time-of-day)? We're not sendi
Em Mon, Dec 13, 2010 at 08:08:08PM +0100, Francis Moreau escreveu:
> Arnaldo Carvalho de Melo writes:
>
> > Em Mon, Dec 13, 2010 at 04:11:16PM +0100, Francis Moreau escreveu:
> >> But as I said, there's no matching build-id. I understand that -k is
> >> current
Em Thu, Dec 09, 2010 at 01:27:07PM -0700, David Ahern escreveu:
> The symfs argument allows analysis of perf.data file using a locally
> accessible filesystem tree with debug symbols - e.g., tree created
> during image builds, sshfs mount, loop mounted KVM disk images,
> USB keys, initrds, etc. Any
Em Tue, Dec 14, 2010 at 10:24:28AM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Dec 09, 2010 at 01:27:07PM -0700, David Ahern escreveu:
> > The symfs argument allows analysis of perf.data file using a locally
> > accessible filesystem tree with debug symbols - e.g., tree cre
Em Tue, Dec 14, 2010 at 10:52:45AM -0200, Arnaldo Carvalho de Melo escreveu:
> Ok, there are still some problems:
>
> It is escaping the symfs jail for /home/acme/bin/perf,
> /lib64/libpthread-2.5.so
> and kernel modules, investigating...
Those 'G' signals means DSO__
Em Tue, Dec 14, 2010 at 07:27:42AM -0700, David S. Ahern escreveu:
> On 12/14/10 05:52, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Dec 14, 2010 at 10:24:28AM -0200, Arnaldo Carvalho de Melo escreveu:
> I was not aware of realpath. Simple change to symbol__init?
I made symbol__init
Em Tue, Dec 14, 2010 at 07:33:27AM -0700, David S. Ahern escreveu:
> On 12/14/10 07:06, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Dec 14, 2010 at 10:52:45AM -0200, Arnaldo Carvalho de Melo escreveu:
> >> Ok, there are still some problems:
> >> It is escaping the sy
Em Wed, Dec 15, 2010 at 05:57:11PM +0900, Masami Hiramatsu escreveu:
> (2010/12/13 23:21), Arnaldo Carvalho de Melo wrote:
> > Also 'perf probe -L' should look use
> > /usr/src/debug/kernel-2.6.35.fc14/linux-2.6.35.x86_64 as a prefix to look
> > for
> >
Em Sat, Dec 18, 2010 at 03:24:12PM +0100, Francis Moreau escreveu:
>
> Adding linux-perf-users mailing list, hoping that someone out there is
> more interested by this subject.
>
> Francis Moreau writes:
>
> > Hello,
> >
> > I'm just wondering if all tools such as perf could be tracked using
>
Em Mon, Jan 10, 2011 at 11:47:43AM -0700, David Ahern escreveu:
> With latest version of perf-core branch, a variant of perf record hangs:
>
> # /tmp/build-perf/perf record -v -e cs -fo /tmp/perf.data -- sleep 1
> couldn't open /proc/-1/status
> couldn't open /proc/-1/maps
> [ perf record: Woken
Em Mon, Jan 10, 2011 at 11:47:43AM -0700, David Ahern escreveu:
> With latest version of perf-core branch, a variant of perf record hangs:
> # /tmp/build-perf/perf record -v -e cs -fo /tmp/perf.data -- sleep 1
> [ perf record: Captured and wrote 0.003 MB /tmp/perf.data (~120 samples) ]
>
> It sit
Em Tue, Jan 11, 2011 at 09:28:25AM +0100, Thomas Gleixner escreveu:
> On Mon, 10 Jan 2011, Arnaldo Carvalho de Melo wrote:
> > Can you try with this patch, not reverting tglx's patch?
> >
> > diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> &g
Em Tue, Jan 11, 2011 at 09:55:36AM +0100, Thomas Renninger escreveu:
> On Tuesday 11 January 2011 02:36:28 Frederic Weisbecker wrote:
> > It's too late for .37, but it's fine, we just need to add
> > a "Cc: sta...@kernel.org" tag in the patch for it to be
> > backported.
> I'll submit it to stable@
Em Tue, Jan 11, 2011 at 09:49:51AM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Jan 11, 2011 at 09:55:36AM +0100, Thomas Renninger escreveu:
> > On Tuesday 11 January 2011 02:36:28 Frederic Weisbecker wrote:
> > > It's too late for .37, but it's fine, we just
Em Fri, Jan 14, 2011 at 05:49:36PM +0100, Thomas Renninger escreveu:
> On Tuesday 11 January 2011 15:51:34 Arnaldo Carvalho de Melo wrote:
> > Em Tue, Jan 11, 2011 at 09:49:51AM -0200, Arnaldo Carvalho de Melo escreveu:
> > > Looking at it now.
> >
> > Can you try wi
Em Fri, Jan 21, 2011 at 03:30:08PM +0100, Thomas Renninger escreveu:
> Without this patch eye of gnome and firfox will draw the
> boxes black.
> Compare with the other box declartions, looks
> like some typos slipped in which get fixed with this
> patch.
>
> Signed-off-by: Thomas Renninger
> CC:
Em Mon, Jan 24, 2011 at 10:49:13PM +0100, Thomas Renninger escreveu:
> On Monday 24 January 2011 22:28:38 Ingo Molnar wrote:
> > * Frederic Weisbecker wrote:
> >
> > > This may be generally useful to help dealing with tracepoint ABI changes.
> > >
> > > But instead of a global tracing ABI number
Em Mon, Jan 24, 2011 at 11:46:12PM +0100, Frederic Weisbecker escreveu:
> On Mon, Jan 24, 2011 at 11:30:01PM +0100, Thomas Renninger wrote:
> > On Monday 24 January 2011 22:57:55 Arnaldo Carvalho de Melo wrote:
> > > Em Mon, Jan 24, 2011 at 10:49:13PM +0100, Thomas
Em Fri, Jan 28, 2011 at 05:49:00PM +0530, nelakurthi koteswararao escreveu:
>I run the Perftest commands on 2.6.35 tree .
>I want to test perf commands itself whether
>they are producing the correct results or not.
>
>That means..suppose if i have following perf commands
>
Em Fri, Jan 28, 2011 at 09:37:03AM -0500, Vince Weaver escreveu:
> On Fri, 28 Jan 2011, Arnaldo Carvalho de Melo wrote:
> >
> > So far I wrote some that generate tracepoint events, but I can envision
> > for instance, figuring out the size of the L2 processor cache, creating
Em Fri, Jan 28, 2011 at 05:03:06PM -0500, Vince Weaver escreveu:
> On Fri, 28 Jan 2011, Arnaldo Carvalho de Melo wrote:
> > My expectation so far, for basic tests, is not to precisely detect each
> > and every event, but to make sure that if a big number of cache misses
> >
Em Fri, Jan 28, 2011 at 02:41:37PM -0700, David Ahern escreveu:
>
>
> On 01/28/11 14:18, Arun Sharma wrote:
> > On Tue, Jan 25, 2011 at 6:29 PM, David Ahern wrote:
> >> From a brief glance seems similar to the timehist patch I proposed. See:
> >> http://www.mail-archive.com/linux-perf-users@vger
Em Fri, Feb 04, 2011 at 07:57:00PM +, Maucci, Cyrille escreveu:
> Yep. I was not promoting caliper here.
> I was just referring to it so that we may get an idea of what he'd like to
> see in 'perf' reports.
Right, useful pointers, thanks, barring patents, I think we can get that
with perf at
Em Wed, Feb 09, 2011 at 06:50:09PM -0800, Arun Sharma escreveu:
> [ Not sure if this is known and fixed in newer kernels. My machine
> becomes unusable after this warning triggers ]
>
> perf record -g -p cs -o csw.data -- sleep 3
What kernel are you using? Peter, rings any bells?
- Arnaldo
>
Em Thu, Feb 10, 2011 at 12:02:20PM -0800, Arun Sharma escreveu:
> On Thu, Feb 10, 2011 at 11:08 AM, Arnaldo Carvalho de Melo
> wrote:
> > Em Wed, Feb 09, 2011 at 06:50:09PM -0800, Arun Sharma escreveu:
> >> [ Not sure if this is known and fixed in newer kernels. My machine
Em Thu, Feb 10, 2011 at 12:46:07PM -0800, Arun Sharma escreveu:
> On Thu, Feb 10, 2011 at 12:20 PM, Arnaldo Carvalho de Melo wrote:
> >> >> perf record -g -p cs -o csw.data -- sleep 3
> > Arun, are you shure the above line is right? I guess it should read:
> &g
Em Fri, Feb 11, 2011 at 12:31:11PM -0800, Arun Sharma escreveu:
> On Fri, Feb 11, 2011 at 12:21 PM, Can Hankendi wrote:
> > Thanks for the reply. I've tried perf record -C 0 -e cycles sleep 1 but i
> > received an error: Couldn't record kernel reference relocation symbol. Is it
> > possible to cr
Em Mon, Feb 14, 2011 at 12:08:28PM -0800, Arun Sharma escreveu:
> On Mon, Feb 14, 2011 at 11:44 AM, Arnaldo Carvalho de Melo wrote
> >> http://perfmon2.git.sourceforge.net/git/gitweb.cgi?p=perfmon2/libpfm4;a=blob;f=python/sys.py;h=e3a44f24174b979694e2588592f7590
Em Mon, Feb 14, 2011 at 02:04:35PM -0800, Arun Sharma escreveu:
> On Mon, Feb 14, 2011 at 12:48 PM, Arnaldo Carvalho de Melo wrote
> >> Potentially, perf itself could be structured as a set of shared
> >> libraries, which are then glued together using a scripting language.
Em Wed, Feb 16, 2011 at 08:43:45AM -0700, David Ahern escreveu:
> Latest perf-core (pulled 5 minutes ago):
>
> # ps -C sshd
> PID TTY TIME CMD
> 961 ?00:00:00 sshd
> 1042 ?00:00:00 sshd
>
> # /tmp/build-perf/perf record -v -fo/tmp/perf.data -p 1042
> Warning: ...
Em Fri, Feb 18, 2011 at 07:33:28AM -0700, David Ahern escreveu:
> On 02/18/11 04:00, Peter Zijlstra wrote:
> > On Thu, 2011-02-17 at 22:53 -0700, David Ahern wrote:
> >> This check does not work out for 64-bit counter:
> >>
> >> sizeof(u32) + sizeof(u64) = 4 + 8 = 12
> >>
> >> which does not pa
Em Fri, Feb 18, 2011 at 04:01:31PM +0100, Peter Zijlstra escreveu:
> On Fri, 2011-02-18 at 12:53 -0200, Arnaldo Carvalho de Melo wrote:
> > > So size should be changed to u64 rather than modifying the
> > WARN_ON_ONCE?
> >
> > Yeah, I guess so, 32-bit has to di
Em Fri, Feb 18, 2011 at 06:59:30PM +0100, Frederic Weisbecker escreveu:
> sched:sched_wait_task [Tracepoint event]
> sched:sched_wakeup [Tracepoint event]
> sched:sched_wakeup_new [Tracepoint event]
> sched:sched_switch
Em Fri, Feb 18, 2011 at 11:53:16AM -0700, David Ahern escreveu:
> On 02/18/11 11:41, Arnaldo Carvalho de Melo wrote:
> > Think about tcpdump + networking tracepoints or 'perf probe' dynamic
> > events in the network stack, he wants to merge those logs and correlate
> &
Em Fri, Feb 18, 2011 at 08:29:56PM +0100, Frederic Weisbecker escreveu:
> On Fri, Feb 18, 2011 at 04:41:19PM -0200, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Feb 18, 2011 at 06:59:30PM +0100, Frederic Weisbecker escreveu:
> > > The timestamps will be the cpu time and not th
Em Sat, Feb 19, 2011 at 10:32:16AM +0100, Ingo Molnar escreveu:
> * David Ahern wrote:
>
> > On 01/23/11 at 03:45:67 a syslog event noted an application restart.
> > Checking the applications logs it went silent. Why? What does perf say?
> >
> > Oh, 2 days have gone by before said event is repor
Em Tue, Mar 01, 2011 at 09:11:20AM -0700, David Ahern escreveu:
> On 03/01/2011 08:11 AM, Frederic Weisbecker wrote:
> > Why shouldn't it be designed to dump software events? It's called
> > print_event().
> > Its current version is rather something I would call "limited". But it
> > was not desig
Em Tue, Mar 01, 2011 at 09:45:27AM -0700, David Ahern escreveu:
>
>
> On 03/01/2011 09:37 AM, Peter Zijlstra wrote:
> > On Tue, 2011-03-01 at 09:09 -0700, David Ahern wrote:
> >>
> >> I did not code it create samples of a realtime-clock event; I coded it
> >> to add an event to the stream on dema
Em Tue, Mar 01, 2011 at 02:07:50PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Mar 01, 2011 at 09:45:27AM -0700, David Ahern escreveu:
> > On 03/01/2011 09:37 AM, Peter Zijlstra wrote:
> > > On Tue, 2011-03-01 at 09:09 -0700, David Ahern wrote:
> > >>
&
dangling symlinks in the case that
even can't be removed with perf-buildid-cache(1).
LKML-Reference:
Signed-off-by: Franck Bui-Huu
Signed-off-by: Arnaldo Carvalho de Melo
[acme@emilia linux]$ git describe 68a7a771
v2.6.37-rc5-71-g68a7a77
So I'll add a CC: sta.
ec7b2925b4682f33c70c0a7eb17
> Author: Arnaldo Carvalho de Melo
> Date: Wed Mar 9 07:48:24 2011 -0300
>
> perf evsel: Assume rest of perf_header_attr functions
>
> commit e62e48df064b431029658089ab1f8b529ff6da3d
> Author: Arnaldo Carvalho de Melo
> Date: Tue Mar 8 0
Em Thu, Mar 10, 2011 at 11:49:28AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Mar 09, 2011 at 09:59:39PM -0800, Arun Sharma escreveu:
> > I pulled the perf/core branch in
> > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux-2.6.git today
> > and found that:
Em Thu, Mar 10, 2011 at 10:20:53AM -0500, Steven Rostedt escreveu:
> On Wed, Mar 09, 2011 at 10:23:25PM -0700, David Ahern wrote:
> > This change does impact output: latency data is trace specific and is now
> > printed after the common data - comm, tid, cpu, time and event name.
> > Signed-off-by
Em Thu, Mar 10, 2011 at 11:05:35AM -0500, Steven Rostedt escreveu:
> On Thu, 2011-03-10 at 12:51 -0300, Arnaldo Carvalho de Melo wrote:
> > David is kinda new to this perf/ftrace/trace-cmd/etc soap opera, and he
> Lucky him ;)
:-)
> > has been patient to go thru the motions
Em Thu, Mar 10, 2011 at 12:28:07PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Mar 10, 2011 at 11:49:28AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Wed, Mar 09, 2011 at 09:59:39PM -0800, Arun Sharma escreveu:
> > > I pulled the perf/core branch in
> > > g
Em Fri, Mar 11, 2011 at 11:51:22AM +0100, Frederic Weisbecker escreveu:
> On Thu, Mar 10, 2011 at 07:48:16AM +0100, Ingo Molnar wrote:
> > * Frederic Weisbecker wrote:
> > > But your idea of turning the callee into the caller would show us a very
> > > global
> > > profiling. With reverse callc
Em Mon, Mar 14, 2011 at 05:51:21PM +0800, 陳韋任 escreveu:
> I have some problems while building perf on a Linux/SPARC machine.
> Here is the system information.
>
> $ uname -a
> Linux sparc 2.6.37-rc5-git #1 SMP Tue Dec 21 17:03:53 CST 2010 sparc64 sun4v
> UltraSparc T2 (Niagara2) GNU/Linux
> $ g
ools/perf/util/symbol.h
> @@ -201,6 +201,7 @@ enum dso_origin {
> DSO__ORIG_GUEST_KMODULE,
> DSO__ORIG_KMODULE,
> DSO__ORIG_NOT_FOUND,
> + DSO__ORIG_END,
> };
commit e988a8fbd20e5562399f802c69276aa42938e229
Author: Arnaldo Carvalho de Melo
Date: Tue Mar 22 15:42:14 2011 -0300
Em Fri, Mar 25, 2011 at 12:05:50PM -0600, David Ahern escreveu:
> Resend of patch sent back in January 2011 in light of recent confusion around
> unsupported events for a given platform.
>
> Improve sys_perf_event_open ENOENT return handling in top and record, just
> like 5a3446b does for stat.
>
Em Fri, Mar 25, 2011 at 12:26:41PM -0600, David Ahern escreveu:
> On 03/25/11 12:08, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Mar 25, 2011 at 12:05:50PM -0600, David Ahern escreveu:
> >> Resend of patch sent back in January 2011 in light of recent confusion
> >> aro
Em Sun, Apr 03, 2011 at 08:35:00AM -0600, David Ahern escreveu:
> +++ b/tools/perf/builtin-script.c
> @@ -94,41 +95,111 @@ static bool output_set_by_user(void)
> +static const char *output_field2str(enum perf_output_field field)
> +{
> + int i, imax = sizeof(all_output_options) / sizeof(struct
Em Mon, May 09, 2011 at 11:28:23AM -0700, Arun Sharma escreveu:
>
> For long running binaries which may have been replaced or deleted, today
> perf top spits out a warning and doesn't show anything. For eg:
>
> test.c:
>
> main()
> {
> while(1);
> }
>
> gcc -O2 test.c -o test
> ./test &
Em Fri, May 27, 2011 at 10:51:46AM -0600, David Ahern escreveu:
> diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
> index f79bb2c..57eccf1 100644
> --- a/tools/perf/util/evsel.h
> +++ b/tools/perf/util/evsel.h
> @@ -61,6 +61,7 @@ struct perf_evsel {
> off_t id
Em Tue, May 10, 2011 at 06:03:05PM -0700, Arun Sharma escreveu:
> [ Not sure if this is the best way to do it. Suggestions welcome ]
>
> All samples that couldn't be resolved are attributed to this
> synthetic symbol. This way, perf top correctly attributes the
> samples to the right dso, even tho
Em Thu, Jun 02, 2011 at 04:20:18PM -0300, Arnaldo Carvalho de Melo escreveu:
> The first patch is fine (dso->deleted) and I applied it, thanks.
oops, it has a problem as well, we can't set ->deleted when we just
didn't found a symtab (stripped binary) fixing that.
- Arnald
Em Thu, Jun 02, 2011 at 04:22:49PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Jun 02, 2011 at 04:20:18PM -0300, Arnaldo Carvalho de Melo escreveu:
> > The first patch is fine (dso->deleted) and I applied it, thanks.
>
> oops, it has a problem as well, we can't set
Em Fri, Jun 03, 2011 at 09:21:41AM +, Kumar Ranjit-B04060 escreveu:
> I am able to do profiling using perf record and report for a 32 bit
> application but for 64 bit application, its not able to resolve the
> symbols. Anyone faced similar problem??
> I am doing this for e5500 core.
Can you
Em Thu, Jun 09, 2011 at 02:44:19PM +0800, Sam Liao escreveu:
> Add "caller/callee" option to support inverted butterfly report,
> in the inverted report (with caller option), the call graph start
> from the callee's ancestor. Users can use such view to catch system's
> performance bottleneck from a
Em Mon, Aug 29, 2011 at 03:55:24PM -0600, David Ahern escreveu:
> Currently, analyzing PPC data files on x86 the cpu field is always 0 and
> the tid and pid are backwards. For example, analyzing a PPC file on PPC
> the pid/tid fields show:
> rsyslogd 1210/1212
>
> and analyzing the same P
Em Fri, Sep 02, 2011 at 10:03:46AM -0600, David Ahern escreveu:
> if (type & PERF_SAMPLE_RAW) {
> - u32 *p = (u32 *)array;
> + u.val64 = *array;
> + if (swapped) {
> + static bool show_warn = true;
> +
> + /* undo swa
Em Fri, Sep 02, 2011 at 01:12:30PM -0600, David Ahern escreveu:
> On 09/02/2011 12:18 PM, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Sep 02, 2011 at 10:03:46AM -0600, David Ahern escreveu:
> >>if (type & PERF_SAMPLE_RAW) {
> >> - u32 *p = (u32 *
Em Fri, Sep 02, 2011 at 01:41:51PM -0600, David Ahern escreveu:
> @@ -423,18 +449,25 @@ int perf_event__parse_sample(const union perf_event
> *event, u64 type,
> }
>
> if (type & PERF_SAMPLE_RAW) {
> - u32 *p = (u32 *)array;
> + u.val64 = *array;
> +
Em Tue, Sep 06, 2011 at 09:12:26AM -0600, David Ahern escreveu:
> v3 -> v4:
> - fixed use of WARN_ONCE
>
> v2 -> v3:
> - used WARN_ONCE for message regarding raw data
> - removed struct wrapper around union
> - fixed whitespace issues
>
> v1 -> v2:
> - added a union for undoing the byte-swap on u
Em Fri, Oct 14, 2011 at 03:25:49PM -0600, David Ahern escreveu:
>
>
> On 10/14/2011 12:36 AM, Roland Dreier wrote:
> > Anyway, suppose I have a multithreaded userspace app that uses a bunch of
> > pthread_mutexes, and I want to figure out which locks are hot and/or heavily
> > contended. What's
Em Mon, Nov 28, 2011 at 06:02:27AM -0800, Arjan van de Ven escreveu:
> On 11/28/2011 3:42 AM, Peter Zijlstra wrote:
> > On Mon, 2011-11-28 at 12:03 +0300, Andrew Vagin wrote:
> >> This tracepoint shows how long a task is sleeping in uninterruptible state.
> >> E.g.
> >> It may show how long and wh
Em Mon, Nov 28, 2011 at 06:43:35AM -0800, Arjan van de Ven escreveu:
> > perf_evlist is what you call perf_bundle and perf_evsel is what you call
> > perf_event in powertop.
> > That part of the API should be ok for wider use and is in fact exported
> > in the python binding.
>
> I don't care abo
Em Tue, Dec 06, 2011 at 11:15:07AM +0400, Andrey Vagin escreveu:
> Hello Arnaldo,
>
> I found, that you commit patches for perf. Could you review this part?
>
> Arun Sharma said, that the second versions of patches works ok for him.
> (Arun is the first user of this functionality after me.)
I'm
Em Mon, Nov 28, 2011 at 12:03:30PM +0300, Andrew Vagin escreveu:
> Signed-off-by: Andrew Vagin
> ---
> tools/perf/builtin-record.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
This patch doesn't apply in current tip/perf/core as this logic was
moved to perf_evsel/perf_evlist,
1 - 100 of 263 matches
Mail list logo
