From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Theodore Tso <tytso@mit.edu>,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: [RFC][PATCH 0/5] tracing/events: stable tracepoints
Date: Wed, 17 Nov 2010 15:14:43 -0500 [thread overview]
Message-ID: <20101117201443.GA22509@Krystal> (raw)
In-Reply-To: <20101117005357.024472450@goodmis.org>
* Steven Rostedt (rostedt@goodmis.org) wrote:
> We also have name (redundant), ID (should be agnostic), and print_fmt
> (lots of issues).
>
> So the new format looks like this:
>
> [root@bxf ~]# cat /sys/kernel/event/sched_switch/format
> array:prev_comm type:char size:8 count:16 align:1 signed:1;
> field:prev_pid type:pid_t size:32 align:4 signed:1;
> field:prev_state type:char size:8 align:1 signed:1;
> array:next_comm type:char size:8 count:16 align:1 signed:1;
> field:next_pid type:pid_t size:32 align:4 signed:1;
Hrm, this is mixing field and type definitions. How about we organize this in
something that will be both parseable and extensible ?
First, I don't see what exporting the kernel-internal type "pid_t" in there
gives you. Userspace knows nothing about this, so it seems pretty useless.
What do you think of this alternative layout ?
Named types below:
% cat /sys/kernel/event/types/char
parent = integer;
size = 8;
signed = true;
align = 8;
% cat /sys/kernel/event/types/pid_t
parent = integer;
size = 32;
signed = true;
align = 32; /* Or 8 if the architecture supports unaligned writes
efficiently */
% cat /sys/kernel/event/sched_switch/format
type { /* Nameless type */
parent = struct;
fields = {
{
type { /* Nameless type */
parent = array;
length = 16;
elem_type = char; /* refers to named type */
},
prev_comm,
},
{ pid_t, prev_pid, },
{ char, prev_state, },
{
type { /* Nameless type */
parent = array;
length = 16;
elem_type = char; /* refers to named type */
},
next_comm,
},
{ pid_t, next_pid, },
};
}
With this layout, we can declare types like enumerations, e.g.
% cat /sys/kernel/event/types/trap_id_t
type {
parent = enum;
size = 5; /* 5-bit bitfield to hold the enumeration */
signed = false;
align = 1; /* bit-packed */
map = {
{ 0, "divide error" },
{ 2, "nmi stack" },
{ 4, "overflow" },
....
};
}
So we can refer to this "named type" in all events for which we want to save
trap ID ? We therefore get the mapping to a human-understandable name for free.
> Some notes:
>
> o The size is in bits.
Yep, this will immensely help when dealing with bitfields.
> o We added an align, that is the natural alignment for the arch of that
> type.
Just watch out, in your initial example, I think your align field is in bytes
rather than bits. Ideally we'd like everything to be consistent.
Thanks,
Mathieu
> o We added an "array" type, that specifies the size of an element as
> well as a "count", where total size can be align(size) * count.
> o We separated the field name from the type.
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
prev parent reply other threads:[~2010-11-17 20:14 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 0:53 [RFC][PATCH 0/5] tracing/events: stable tracepoints Steven Rostedt
2010-11-17 0:53 ` [RFC][PATCH 1/5] [PATCH 1/5] events: Add EVENT_FS the event filesystem Steven Rostedt
2010-11-17 3:32 ` Greg KH
2010-11-17 10:39 ` Ingo Molnar
2010-11-17 12:25 ` Steven Rostedt
2010-11-17 15:03 ` Ingo Molnar
2010-11-17 15:16 ` Peter Zijlstra
2010-11-17 15:16 ` Steven Rostedt
2010-11-17 15:35 ` Peter Zijlstra
2010-11-17 18:42 ` Ted Ts'o
2010-11-17 15:16 ` Peter Zijlstra
2010-11-23 21:29 ` Steven Rostedt
2010-11-17 17:46 ` Mathieu Desnoyers
2010-11-17 17:52 ` Steven Rostedt
2010-11-17 18:12 ` Mathieu Desnoyers
2010-11-18 9:42 ` Avi Kivity
2010-11-17 23:48 ` Ted Ts'o
2010-11-18 13:05 ` Mathieu Desnoyers
2010-11-17 12:16 ` Steven Rostedt
2010-11-17 0:53 ` [RFC][PATCH 2/5] [PATCH 2/5] tracing/events: Add code to (un)register stable events Steven Rostedt
2010-11-17 0:54 ` [RFC][PATCH 3/5] [PATCH 3/5] tracing/events: Add infrastructure to show stable event formats Steven Rostedt
2010-11-17 0:54 ` [RFC][PATCH 4/5] [PATCH 4/5] tracing/events: Add stable event sched_switch Steven Rostedt
2010-11-17 0:54 ` [RFC][PATCH 5/5] [PATCH 5/5] tracing/events: Add sched_migrate_task stable event Steven Rostedt
2010-11-17 20:14 ` Mathieu Desnoyers [this message]
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=20101117201443.GA22509@Krystal \
--to=mathieu.desnoyers@efficios.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/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.