This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: feedback from google

From: Karim Yaghmour <karim at opersys dot com>
To: "Frank Ch. Eigler" <fche at redhat dot com>
Cc: systemtap at sources dot redhat dot com
Date: Fri, 13 May 2005 15:51:06 -0400
Subject: Re: feedback from google
Organization: Opersys inc.
References: <75EC4D5486CAC247B84AAAA6F96AA5580498C08F@orsmsx402.amr.corp.intel.com> <4284EF06.6090003@opersys.com> <y0mr7gbdkto.fsf@toenail.toronto.redhat.com>
Reply-to: karim at opersys dot com

Frank Ch. Eigler wrote:
> OK, though especially relayfs assumes that all that trace data has to
> be dumped to user space, rather than being filtered/aggregated in the
> kernel.

There's nothing stopping the tracing layer in the kernel to filter/
aggregate. That's a definitive limitation of the existing LTT:
the inability of having pluggable filtering/aggregation.

> It should not be hard to associate systemtap probes with static
> instrumentation points, without using kprobes, and thus avoiding the
> cost of an interrupt.

Definitely. That would be great.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546

References:
- feedback from google
  - From: Chen, Brad
- Re: feedback from google
  - From: Karim Yaghmour
- Re: feedback from google
  - From: Frank Ch. Eigler

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]