All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Ingo Molnar <mingo@elte.hu>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Rostedt <rostedt@goodmis.org>,
	tglx@linutronix.de, Jason Baron <jbaron@redhat.com>,
	"Frank Ch. Eigler" <fche@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Jiaying Zhang <jiayingz@google.com>,
	Michael Rubin <mrubin@google.com>,
	Martin Bligh <mbligh@google.com>,
	Michael Davidson <md@google.com>
Subject: Re: [PATCH 0/2 v2] Syscalls tracing
Date: Mon, 23 Mar 2009 16:37:55 -0400	[thread overview]
Message-ID: <20090323203754.GA29941@Krystal> (raw)
In-Reply-To: <20090323194020.GA29478@elte.hu>

* Ingo Molnar (mingo@elte.hu) wrote:
> 
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> 
> > And actually I don't think two copy_from_user will really change a 
> > lot the tracing throughput.
> 
> Correct. It's already in the CPU cache so it is a performance 
> non-issue and essentially for free. Copy avoidance is only an issue 
> when touchig cache-cold data.
> 
> ( Yes, a few cycles could be shaven off but the beauty of 
>   all-encompassing non-source-code-invasive syscall tracing covering 
>   hundreds of syscalls straight away trumps those concerns. )
> 

I agree. I just wanted to make sure we agreed on the tradeoff here. I
also think hitting data already in cache-lines a second time with
copy_from_user should not be a big concern.

> > The idea would be now to join the syscalls metadata with such 
> > quick handlers. We will have to think about how to join these in a 
> > proper way.
> 
> We could allow per syscall tracepoints via the attribute table. The 
> call signature could be a standard:
> 
>    long sys_call(unsinged long arg1, unsigned long arg2,
> 		 unsigned long arg3, unsigned long arg4,
> 		 unsigned long arg5, unsigned long arg6);
> 
> This would allow interested plugins/tools to install a system call 
> specific callback. (we might allow two tracepoints - one before and 
> one after the syscall)
> 
> The registration API could be driven by the name or by the syscall 
> index - NR_sys_open or so.

Hrm, given the syscalls are defined with their number of arguments
with the SYSCALL_DEFINE* macros, then we could create, in syscalls.h
(example from open.c) :

SYSCALL_DECLARE2(statfs, const char __user *, pathname, struct statfs __user *, buf))

SYSCALL_DECLARE3(statfs64, const char __user *, pathname, size_t, sz, struct statfs64 __user *, buf)

creating SYSCALL_DECLARE0 to 6, which would map to a tracepoint
declaration _and_ a syscall prototype, e.g.

#define __SC_ARGS1(t1, a1)      a1
#define __SC_ARGS2(t2, a2, ...) a2, __SC_ARGS1(__VA_ARGS__)
#define __SC_ARGS3(t3, a3, ...) a3, __SC_ARGS2(__VA_ARGS__)
#define __SC_ARGS4(t4, a4, ...) a4, __SC_ARGS3(__VA_ARGS__)
#define __SC_ARGS5(t5, a5, ...) a5, __SC_ARGS4(__VA_ARGS__)
#define __SC_ARGS6(t6, a6, ...) a6, __SC_ARGS5(__VA_ARGS__)

#define SYSCALL_DECLARE2(name, ...) SYSCALL_DECLAREx(2, _##name, __VA_ARGS__) 

#define SYSCALL_DECLAREx(x, name, ...)				\
	long sys##name(__SC_DECL##x(__VA_ARGS__));		\
	DECLARE_TRACE(sys_##name,				\
			TP_PROTO(__SC_DECL##x(__VA_ARGS__)),	\
				TP_ARGS(__SC_ARGS##x(__VA_ARGS__)))

Those could be declared in a system-wide header (syscalls.h ?) which
would be included by each files using SYSCALL_DEFINE*. Those
declarations would declare the tracepoints and therefore make sure we
spot any SYSCALL_DEFINE* change at compile-time, and we could create a
tracing module which would contain the callbacks that would register on
those syscall tracepoint declarations. This would all be type-safe,
which is a very nice thing to have, even if we don't expect the system
calls to change often at all.

Mathieu

> 
> 	Ingo

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

      reply	other threads:[~2009-03-23 20:38 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-13 14:42 [PATCH 0/2 v2] Syscalls tracing Frederic Weisbecker
2009-03-13 14:42 ` [PATCH 1/2 v2] tracing/syscalls: core infrastructure for syscalls tracing Frederic Weisbecker
2009-03-13 16:09   ` [tip:tracing/syscalls] tracing/syscalls: core infrastructure for syscalls tracing, enhancements Frederic Weisbecker
2009-03-15  3:51   ` [PATCH 1/2 v2] tracing/syscalls: core infrastructure for syscalls tracing Andrew Morton
2009-03-15  4:59     ` Ingo Molnar
2009-03-15  8:02       ` Andrew Morton
2009-03-15 16:17         ` Frederic Weisbecker
2009-04-06 21:55   ` Tony Luck
2009-04-06 22:12     ` Frederic Weisbecker
2009-04-07  0:30       ` Steven Rostedt
2009-04-08 18:40     ` [PATCH] tracing/syscalls: use a dedicated file header Frederic Weisbecker
2009-04-08 19:36       ` Luck, Tony
2009-04-08 22:44         ` Steven Rostedt
2009-04-08 22:51           ` Luck, Tony
2009-04-08 23:02             ` Steven Rostedt
2009-04-08 23:08           ` Luck, Tony
2009-04-08 23:32             ` Steven Rostedt
2009-04-08 23:32             ` Joe Perches
2009-04-09  0:15         ` [GIT PULL][PATCH] " Steven Rostedt
2009-04-09  4:36       ` [tip:tracing/urgent] " Frederic Weisbecker
2009-03-13 14:42 ` [PATCH 2/2 v2] tracing/syscalls: support for syscalls tracing on x86-64 Frederic Weisbecker
2009-03-13 16:09   ` [tip:tracing/syscalls] tracing/syscalls: support for syscalls tracing on x86 Frederic Weisbecker
2009-03-15  3:53   ` [PATCH 2/2 v2] tracing/syscalls: support for syscalls tracing on x86-64 Andrew Morton
2009-03-15  5:30     ` Ingo Molnar
2009-03-15 16:05       ` Frederic Weisbecker
2009-03-13 15:16 ` [PATCH 0/2 v2] Syscalls tracing Frederic Weisbecker
2009-03-13 15:55   ` Ingo Molnar
2009-03-13 16:17     ` Ingo Molnar
2009-03-15 15:25       ` Frederic Weisbecker
2009-03-13 16:47   ` Mathieu Desnoyers
2009-03-15 16:01     ` Frederic Weisbecker
2009-03-23 16:32       ` Mathieu Desnoyers
2009-03-23 19:27         ` Frederic Weisbecker
2009-03-23 19:40           ` Ingo Molnar
2009-03-23 20:37             ` 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=20090323203754.GA29941@Krystal \
    --to=mathieu.desnoyers@polymtl.ca \
    --cc=a.p.zijlstra@chello.nl \
    --cc=fche@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=jbaron@redhat.com \
    --cc=jiayingz@google.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@google.com \
    --cc=md@google.com \
    --cc=mingo@elte.hu \
    --cc=mrubin@google.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.