From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Pawel Moll <pawel.moll@arm.com>
Cc: Richard Cochran <richardcochran@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Paul Mackerras <paulus@samba.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
John Stultz <john.stultz@linaro.org>,
Christopher Covington <cov@codeaurora.org>,
Namhyung Kim <namhyung@kernel.org>,
David Ahern <dsahern@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Tomeu Vizoso <tomeu@tomeuvizoso.net>,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
Pawel Moll <mail@pawelmoll.com>
Subject: Re: [PATCH v3 0/3] perf: User/kernel time correlation and event generation
Date: Tue, 04 Nov 2014 18:24:40 +0900 [thread overview]
Message-ID: <54589B58.7080102@hitachi.com> (raw)
In-Reply-To: <1415060918-19954-1-git-send-email-pawel.moll@arm.com>
Hello,
(2014/11/04 9:28), Pawel Moll wrote:
> 2. User event generation
>
> Everyone present agreed that it would be a very-nice-to-have feature.
> There was some discussion about implementation details, so I welcome
> feedback and comments regarding my take on the matter.
Hmm, I'm trying to make a similar thing, dynamic event definition via
ftrace, which is already done by kprobes/uprobes. And this will be shown
as dynamic events from perf too.
What I'd like to do is the binary version of ftrace-marker, the text
version is already supported by qemu (see below).
https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg00505.html
But since that is just a string data (not structured data), it is hard to
analyze via perf-script or some other useful filters/triggers in ftrace.
In my idea, the new event will be defined via a special file in debugfs like
kprobe-events, like below.
# cd $debugfs/tracing
# echo "newgrp/newevent signarg:s32 flag:u64" >> marker_events
# cat events/newgrp/newevent/format
name: newevent
ID: 2048
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1;signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:s32 signarg; offset:8; size:4; signed:1;
field:u64 flag; offset:12; size:8; signed:0;
print fmt: "signarg=%d flag=0x%Lx", REC->signarg, REC->flag
Then, users will write the data (excluded common fields) when the event happens
via trace_marker which start with '\0'ID(in u32). Kernel just checks the ID and
its data size, but doesn't parse, filter/trigger it and log it into the kernel buffer.
Of course, this has a downside that the user must have a privilege to access to debugfs.
Thus maybe we need both of prctl() IF for perf and this IF for ftrace.
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2014-11-04 9:24 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-04 0:28 [PATCH v3 0/3] perf: User/kernel time correlation and event generation Pawel Moll
2014-11-04 0:28 ` Pawel Moll
[not found] ` <1415060918-19954-1-git-send-email-pawel.moll-5wv7dgnIgG8@public.gmane.org>
2014-11-04 0:28 ` [PATCH v3 1/3] perf: Use monotonic clock as a source for timestamps Pawel Moll
2014-11-04 0:28 ` Pawel Moll
[not found] ` <1415060918-19954-2-git-send-email-pawel.moll-5wv7dgnIgG8@public.gmane.org>
2014-11-04 7:23 ` Peter Zijlstra
2014-11-04 7:23 ` Peter Zijlstra
[not found] ` <20141104072308.GE10501-IIpfhp3q70z/8w/KjCw3T+5/BudmfyzbbVWyRVo5IupeoWH0uzbU5w@public.gmane.org>
2014-11-04 15:25 ` Pawel Moll
2014-11-04 15:25 ` Pawel Moll
[not found] ` <1415114727.24819.8.camel-5wv7dgnIgG8@public.gmane.org>
2014-11-04 15:30 ` Peter Zijlstra
2014-11-04 15:30 ` Peter Zijlstra
2014-11-04 0:28 ` [PATCH v3 3/3] perf: Sample additional clock value Pawel Moll
2014-11-04 0:28 ` Pawel Moll
2014-11-04 0:58 ` [PATCH v3 0/3] perf: User/kernel time correlation and event generation Andy Lutomirski
2014-11-04 0:58 ` Andy Lutomirski
[not found] ` <CALCETrXGoevmD_avz5sQfbbD624vpLW5=-8ovzTPT_5wzNFnVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-04 1:11 ` John Stultz
2014-11-04 1:11 ` John Stultz
[not found] ` <CALAqxLXfy5P0kg-W7hL+Jf1iYv758+-2cTdZwsY8kAns1nvEmg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-04 1:25 ` Andy Lutomirski
2014-11-04 1:25 ` Andy Lutomirski
[not found] ` <CALCETrUAkXKyXzZy4xaYcW2f65Lh=APrU4cFU1zm-qmc6EwB8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-04 15:07 ` Pawel Moll
2014-11-04 15:07 ` Pawel Moll
2014-11-04 8:01 ` Arnd Bergmann
2014-11-04 8:01 ` Arnd Bergmann
2014-11-04 8:27 ` Richard Cochran
2014-11-04 8:27 ` Richard Cochran
[not found] ` <20141104082728.GB4253-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2014-11-04 10:49 ` Thomas Gleixner
2014-11-04 10:49 ` Thomas Gleixner
2014-11-04 16:11 ` Arnd Bergmann
2014-11-04 16:04 ` John Stultz
2014-11-04 16:04 ` John Stultz
2014-11-04 8:24 ` Richard Cochran
2014-11-04 8:24 ` Richard Cochran
2014-11-04 0:28 ` [PATCH v3 2/3] perf: Userspace event Pawel Moll
2014-11-04 6:33 ` Namhyung Kim
[not found] ` <87ppd35vbk.fsf-vfBCOVm4yAnB69T4xOojN9BPR1lH4CV8@public.gmane.org>
2014-11-04 16:42 ` Pawel Moll
2014-11-04 16:42 ` Pawel Moll
[not found] ` <1415119331.24819.19.camel-5wv7dgnIgG8@public.gmane.org>
2014-11-04 18:40 ` Peter Zijlstra
2014-11-04 18:40 ` Peter Zijlstra
[not found] ` <20141104184031.GM10501-IIpfhp3q70z/8w/KjCw3T+5/BudmfyzbbVWyRVo5IupeoWH0uzbU5w@public.gmane.org>
2014-11-05 6:36 ` Namhyung Kim
2014-11-05 6:36 ` Namhyung Kim
2014-11-04 9:24 ` Masami Hiramatsu [this message]
[not found] ` <54589B58.7080102-FCd8Q96Dh0JBDgjK7y7TUQ@public.gmane.org>
2014-11-04 15:51 ` [PATCH v3 0/3] perf: User/kernel time correlation and event generation Pawel Moll
2014-11-04 15:51 ` Pawel Moll
[not found] ` <1415116269.24819.14.camel-5wv7dgnIgG8@public.gmane.org>
2014-11-05 8:06 ` Masami Hiramatsu
2014-11-05 8:06 ` Masami Hiramatsu
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=54589B58.7080102@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=acme@kernel.org \
--cc=cov@codeaurora.org \
--cc=dsahern@gmail.com \
--cc=john.stultz@linaro.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mail@pawelmoll.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=paulus@samba.org \
--cc=pawel.moll@arm.com \
--cc=peterz@infradead.org \
--cc=richardcochran@gmail.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tomeu@tomeuvizoso.net \
/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.