From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Stanislav Fomichev <stfomichev@yandex-team.ru>
Cc: a.p.zijlstra@chello.nl, paulus@samba.org,
Ingo Molnar <mingo@kernel.org>,
dsahern@gmail.com, jolsa@redhat.com,
xiaoguangrong@linux.vnet.ibm.com, yangds.fnst@cn.fujitsu.com,
adrian.hunter@intel.com, namhyung@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/7] perf trace pagefaults
Date: Tue, 24 Jun 2014 11:15:01 -0300 [thread overview]
Message-ID: <20140624141501.GA3456@kernel.org> (raw)
In-Reply-To: <20140623114139.GB20225@stfomichev-desktop.yandex.net>
Em Mon, Jun 23, 2014 at 03:41:39PM +0400, Stanislav Fomichev escreveu:
> > > But we then need to predefine many probes for decoding to work in the form of
> > > func:offset, and then play catch-up with all the kernel changes.
> > > Or I miss something important here?
> > No you don't.
> > If we want to disturb the system in the least way possible, we need to
> > tag along the copying from userspace of those pointers, so that we get
> > them fresh and just stash it in our ring buffer and get out of the way
> > quickly.
> I just thought maybe you have some grand plan in mind about automagically
> adding probes so argument tracing works transparently. I like the
> approach though.
First we use what we have in place, then we optimize it.
> > Almost a year ago, and it still works, now lets see the cset you mention...
> >
> > [acme@zoo linux]$ git describe c4ad8f98bef77c7356aa6a9ad9188a6acc6b849d
> > v3.14-rc1-14-gc4ad8f98bef7
> > [acme@zoo linux]$
> > [root@zoo ~]# uname -r
> > 3.15.0-rc8+
> >
> > Humm, what is the problem?
> I thought that result->name was actually set on 65th line of
> getname_flags, so the above commit would move it to 66th. But it's not
> the case, sorry for confusion.
> > [1] And I feel like all of tools/perf/ is just that, reference implementations, but hopefully
> > done in a such a way that may well be useful as-is :-)
> I'd like perf to be a goto tool for all kind of performance analysis,
yay, and you're working for that, thanks!
> not just a reference implementation. I believe nobody looks at this
> reference, and we end up with tools like https://github.com/draios/sysdig
Never heard about it, will take a look, thanks for the pointer.
> which do their own events, ring buffer, etc.
There are several out there :)
- Arnaldo
next prev parent reply other threads:[~2014-06-24 14:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-20 10:49 [PATCH v2 0/7] perf trace pagefaults Stanislav Fomichev
2014-06-20 10:49 ` [PATCH 1/7] perf trace: add perf_event parameter to tracepoint_handler Stanislav Fomichev
2014-06-20 10:49 ` [PATCH 2/7] perf trace: add support for pagefault tracing Stanislav Fomichev
2014-06-20 14:59 ` Arnaldo Carvalho de Melo
2014-06-20 15:49 ` Stanislav Fomichev
2014-06-20 16:11 ` Arnaldo Carvalho de Melo
2014-06-24 12:46 ` Stanislav Fomichev
2014-06-24 15:21 ` Arnaldo Carvalho de Melo
2014-06-20 10:49 ` [PATCH 3/7] perf trace: add pagefaults record and replay support Stanislav Fomichev
2014-06-20 10:49 ` [PATCH 4/7] perf trace: add pagefault statistics Stanislav Fomichev
2014-06-20 10:49 ` [PATCH 5/7] perf trace: add possibility to switch off syscall events Stanislav Fomichev
2014-06-20 10:49 ` [PATCH 6/7] perf kvm: move perf_kvm__mmap_read into session utils Stanislav Fomichev
2014-06-20 14:44 ` Arnaldo Carvalho de Melo
2014-06-20 15:07 ` Stanislav Fomichev
2014-06-20 15:25 ` Arnaldo Carvalho de Melo
2014-06-23 14:06 ` David Ahern
2014-06-23 14:14 ` Stanislav Fomichev
2014-06-20 10:49 ` [PATCH 7/7] perf trace: add events cache Stanislav Fomichev
2014-06-20 13:21 ` [PATCH v2 0/7] perf trace pagefaults Arnaldo Carvalho de Melo
2014-06-20 15:03 ` Stanislav Fomichev
2014-06-20 15:24 ` Arnaldo Carvalho de Melo
2014-06-20 16:18 ` Stanislav Fomichev
2014-06-20 18:30 ` Arnaldo Carvalho de Melo
2014-06-23 11:41 ` Stanislav Fomichev
2014-06-24 14:15 ` Arnaldo Carvalho de Melo [this message]
2014-06-23 14:00 ` David Ahern
2014-06-24 7:17 ` Namhyung Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140624141501.GA3456@kernel.org \
--to=acme@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=adrian.hunter@intel.com \
--cc=dsahern@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=paulus@samba.org \
--cc=stfomichev@yandex-team.ru \
--cc=xiaoguangrong@linux.vnet.ibm.com \
--cc=yangds.fnst@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.