Re: Profiling functions on the call stack

[David S. <ds...@al...>]

Philippe Elie wrote:
> 
> Ok, as I can see your code, it is, at least, a good start point. One main
> difference with your last post is the use of only one counter which means
> that post-profile can't differenciate between back-trace samples and
> samples. How do you see interpretation of results in post-profile tools ?
> 

I didn't mean to leave that out forever. I just thought that getting a
reliable and stable backtrace it the important thing. And hardcoding 
counters 1 and 0 was not really a lasting solution anyway... :-)

Maybe backtrace samples could always be put in 'ctr+1'. Two new options
to op_start, "--rtc-backtrace" and "--ctrN-backtrace", could be used to
turn it on. But that's just hypothetical anyway until the actual
backtrace
code is solid.

> 
> on x86 even if it is not a hardware requirement you can check than ebp
> is aligned
> on a 4 byte boundary.
> 
> John suggest than a check than new_ebp - old_ebp < few Megs can improve
> reliability (the threshold needs to be user set-able)
> 

Yes, those checks would be good. I think any simple and fast check
would be good to improve reliability.

I've also thought about checking the return address: it should be after
a call instruction and it should be in a code segment. I'm not sure,
however, how much is justified from a performance perspective.

> On SMP afaik we can't do anything is nmi handler, I dunno if at mmap time
> we can lock all applications stack but it's an ugly work-around and 
> don't work
> for process already started at profiling start.

Why can't we do anything in an NMI handler on SMP?  (Just so you know:
I'm still learning, and especially about SMP...and I'm running a Pentium
Classic, i.e. rtc and a single processor)

To be clear, this is what I'm concerned about when it comes to SMP.
The code basically does this while backtracing:

  1. get page (from frame pointer)
  2. verify page
  3. access page one or more times
     until a frame is on another page
  4. goto 1

Step 3 is ok on UP since there is no one else that can remove the page
while it's being read. Om SMP I'm afraid of this:

  cpu A                                     cpu B

  1. get page (from frame pointer)          ...
  2. verify page                            ...
     ....                                   remove page (i.e. swap)
  3. access page one or more times          ...
     until a frame is on another page       ...
  4. goto 1                                 ...

That would obviously be a bad thing! Solutions I've been thinking about
use either mm->page_table_lock (not good, though!) or get_page(page) to
lock the page while reading.

Are there other problems that I'm missing?


/David