RE: Attempting to try out "asynchronous probes" and the currentruntime...

["Spirakis, Charles" <charles dot spirakis at intel dot com>]

I haven't don't anything that ambitious yet, though it is a good idea. I
believe part of the problem I would run into is the mapping of the ip
back to the image. Oprofile is using a concept they call dcookies which
splits the work between the kernel (which generates the dcookie) and
user-mode code (which calls the kernel to dereference the dcookie to get
the actual path/image name string). The runtime doesn't have those kinds
of concepts (yet?). Currently it allows for strings and int64's as key's
and data types. Potentially we may want a "dcookie" data type which has
the behavior similar to what oprofile has.

As I continue to experiment, I have created another simple timer that
registers with one of the profile timers that oprofile uses. That
version does give (at first glance) accurate profiling information. I
also started playing with using the dentry/dcookie aspect to generate
the path/image name string from within the interrupt handler (not
preferred, I know, but as an experiment to see the overhead). Assuming
there are no objections, I'll probably combine the current os_timer with
the new profile_timer version into a more generic "timer" version. Most
likely I'll use a module parameter to select between the two.

-- charles


> -----Original Message-----
> From: systemtap-owner@sources.redhat.com 
> [mailto:systemtap-owner@sources.redhat.com] On Behalf Of Martin Hunt
> Sent: Wednesday, July 13, 2005 9:37 AM
> To: Spirakis, Charles
> Cc: systemtap@sources.redhat.com
> Subject: Re: Attempting to try out "asynchronous probes" and 
> the currentruntime...
> 
> On Wed, 2005-07-06 at 20:31 -0700, Spirakis, Charles wrote:
> > All --
> > 
> > I'm playing around with an "asynchronous probe" concept and the 
> > current runtime using simple os timers (code is below). Anyone have 
> > experience with task_pt_regs() function? As you can see, 
> I'm trying to 
> > grab the "current" pt_regs in the home of seeing the eip at 
> the time 
> > of the timer interrupt, but the data I get is not what I'd hoped.
> 
> I tried to figure out that one for some runtime functions and 
> never found a solution.
> 
> Did you consider using the builtin kernel profiling?  
> oprofile uses it.
> It looks like you could take whats in drivers/oprofile and 
> replace all the data collection and transport stuff with 
> runtime functions and have a profiler that worked nicely with 
> systemtap.
> 
> Martin
> 
> 
> 
>