Re: tapset taxonomy

[William Cohen <wcohen at redhat dot com>]

Chen, Brad wrote:
> > In order to let us decide how many of these extensibility points we
> > need to support, we need ... drumroll ... more detailed examples.  My
> > intuition says that the basic library and translator points I marked
> > above with [***] are sufficient for the forseeable future.
> > notion of priviledged script tapsets located in a library

Here are some typical low-level I see for tap set support:

-How many times did that section of code get executed
-What is the context this code is being run in?
-Which process is using this resource.
-Where in the user code triggered use of this resource (e.g. the syscall)
-How long did it take to complete an action?

These actions would be mapped to things that the developer could do 
something about, e.g. generation of ethernet traffic, by the tapset writer.

> I think the list of mine you refer to above is this one:
> - hardware performance counters
> - power management hardware
> - virtualization technologies
> - strange new hardware to support multicore architectures
> Unfortunately, this is not the future; the first three are happening
> now, and the fourth will be with us within a year or so. Dealing with
> some of these can require special libraries, linking conventions or 
> compilation options. It's easy to imagine the compiler support for 
> such options might be somewhat tempermental and inflexible at first.
> I don't think we will understand all the implications before we commit
> to a plan for tapset authoring.

I would like to discuss how we the technologies listed above are going 
to influence the instrumentation and how they might be used in the data 
collection and performance analysis.

Hardware counters have been around for a while. There have been various 
mechanisms incorporated into the kernel to use them, e.g. perfmon, 
perfctr, and oprofile.  What ways do you see the performance monitoring 
hardware being used?  There are a number of different modes of 
operation, e.g. stop watch (caliper mode), sampling, and event logging.

Using the performance monitoring hardware can provide really good 
insight into why there is a performance problem. However, the 
performance monitoring hardware is very processor specific. developing 
instrumentation for this limits the hardware that it can be run on. In 
other cases it is difficult to map the collected data back to something 
the programmer has some control over. One example of this problem is the 
hyperthread P4 do not distinguish which thread a floating point 
instruction came from, making it impossible to figure out which process 
to assign the sample to when doing sampled based profiling.

Brad, how do you see power management hardware affecting the 
instrumentation? Doing things like realizing the memory bus is the 
limiting factor and the processor clock rate can be reduced while still 
getting the same level of performance? Or looking at the power state 
transitions and trying to schedule processes to reduce the number of 
transitions between different power states?

Virtualization is currently available in systems like Xen. 
Virtualization of the special processor hardware such as performance 
monitoring and debugging hardware is an issue there. Should users be 
able to use the performance these processors resources independently of 
other virtual machines. Another issue is getting an overall view of what 
is going on physical machine and the logical processors.

Brad, what did you mean by "strange new hardware to support multicore 
architectures"? Is this things like shared caches or other shared 
resources on the die? Or special mailbox instructions to reduce 
interprocess communications?

-Will