Date:	Thu, 29 Jan 2009 15:31:20 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Frédéric Weisbecker <fweisbec@...il.com>
Cc:	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	powertop ml <power@...host.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	srostedt@...hat.com,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Neil Horman <nhorman@...driver.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	utrace-devel@...hat.com, Roland McGrath <roland@...hat.com>
Subject: Re: [PATCH] tracer for sys_open() - sreadahead


* Frédéric Weisbecker <fweisbec@...il.com> wrote:

> 2009/1/29 Ingo Molnar <mingo@...e.hu>:
> >
> > * Frederic Weisbecker <fweisbec@...il.com> wrote:
> >
> >> On Tue, Jan 27, 2009 at 11:43:03PM +0100, Frederic Weisbecker wrote:
> >> > On Tue, Jan 27, 2009 at 12:08:04PM -0800, Kok, Auke wrote:
> >> > >
> >> > > This tracer monitors regular file open() syscalls. This is a fast
> >> > > and low-overhead alternative to strace, and does not allow or
> >> > > require to be attached to every process.
> >> > >
> >> > > The tracer only logs succesfull calls, as those are the only ones we
> >> > > are currently interested in, and we can determine the absolute path
> >> > > of these files as we log.
> >> > >
> >> > > Signed-off-by: Auke Kok <auke-jan.h.kok@...el.com>
> >> >
> >> >
> >> > Hi Auke,
> >> >
> >> > Speaking about a global syscall tracer, I made a patch to trace only the syscalls
> >> > with the function-graph-tracer.
> >> >
> >> > http://lkml.org/lkml/2008/12/30/267
> >> >
> >> > Its approach and purpose is different than a tracer dedicated only to syscalls.
> >> > The function graph tracer traces execution graph of the functions and is more about
> >> > execution time spent and code flow whereas a syscall tracer can provide more specific
> >> > informations about syscalls.
> >> >
> >> > So both are not overlaping.
> >> >
> >> > But the low level part of my patch creates a thread flag _TIF_SYSCALL_TRACE which triggers
> >>
> >> s/_TIF_SYSCALL_TRACE/_TIF_SYSCALL_FTRACE
> >
> >> > Once we have it, I think a syscall tracer can be fed with new syscalls
> >> > events through several patch iterations, starting with the open and
> >> > close one :-)
> >> >
> >> > Are you ok with that?
> >> >
> >> > Steven, Ingo, do you agree?
> >
> > yes. We definitely need this on the asm syscall level, to not contaminate
> > hundreds of syscalls with tracepoints.
> >
> > Auke's sys_open() plugin would be a nice prototype for that concept - but
> > in generally it would be useful to be able to augment kernel tracer output
> > with all syscall events that occur.
> >
> > The output would be something like a slimmed-down strace, but for the
> > whole kernel and not tied to ptrace semantics (which are crippling).
> >
> > Would you be interested in extending your syscall tracing concept with
> > those bits and would you be interested in integrating Auke's plugin into
> > that
> >
> >        Ingo
> 
> 
> Several people talked me about utrace and gave some examples about it in 
> this discussion. The Api is very convenient to fetch syscall numbers, 
> arguments and return values. And the hooks are done in the generic core 
> code, so it is arch independent.
> 
> The only drawback I can see is that it is not yet merged upstream, in 
> need of in-kernel users. If it only depends on this condition, we could 
> be these users...
> 
> What do you think?

sure - how do the minimal bits/callbacks look like which enable syscall 
tracing?

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists