On Mon, May 22, 2006 at 02:01:15PM -0500, Yeh, Jason wrote:
> > Why the restriction?
> 256 is just an arbitrary number that seems to be a large enough and not
> likely to be exceeded.
If it's arbitrary, then I see no need for a limit other than a natural
> > What happens after a reboot, when tgid's can be reused?
> I feel that the possibility of this situation is small. If a tgid is
> reused by a different process other than a virtual machine, the memory
> allocated for this mapping is simply wasted. Please correct me if I am
> incorrect, I believe it is not likely that samples from regular code
> section will be in the range of generated code.
If there's a chance of data corruption then we need to handle it
> > The idea of using a separate file for each function is
> > interesting, but I do have concerns. First off, we can easily
> > expect a *lot* of such files. Will this be reasonably performant?
> From my prior experience, a *lot* of file is generated by this this
> approach. As for the performance, it depends on how reasonably
> performance is defined. I do not have estimate on how much CPU
> utilization time may be used during sampling and how much time
> post-profiling might take. Performance is definitely the most critical
> factor to consider during the designing and implementation of the
Some data would be useful. It's supposed to be a low-overhead profiler.
If we end up stat()ing huge directories all the time it won't be.
> > Secondly, how would the post-profiling tools gather all of
> > this data into a reasonably human profile. How do you plan to
> > do this? In particular, what would "application name" and
> > "image name" be in this context?
> This is what I have in mind: The "application name" will depend on what
> the profiling agent tells the libagent. It should be along the line of
> Java command line argument.
Fine. How is this stored?
> "image name" will similar to "anonymous
> samples". Each function is still treated as a function even though the
> function's content is stored as a binary image. The reporting tool
> needs to be coded to distinguish the generated code from regular code.
How does the post-profiling code collect up all the binaries into a
single binary? Are you proposing a new op_bfd backend, or what?