Messages in this thread | | | From | (Patrick J. LoPresti) | Subject | Re: Profiling timer not delivered during syscalls? | Date | 01 Nov 1999 21:02:18 -0500 |
| |
andrea> There isn't any timer. -pg will only force gcc to call a andrea> function called mcount() as first thing while entering a new andrea> function call.
Yes there is. When "-pg" is passed to the linker it causes it to link against gcrt0.o instead of crt0.o. The former invokes "monstartup" which starts the profiling timer.
If you don't believe me, try compiling the program exactly as I said to do and then running it. You will observe that the SIGPROF handler is invoked, just not during the select().
It turns out that this behavior is documented in the gprof info pages. (I apologize for sending my message before completely researching the issue.) This turns out to be inconvenient for me: I was trying to make gprof work on a multithreaded program by intercepting SIGPROF in the main thread and forwarding it to the child threads. But in my multithreaded program, the main thread is frequently blocked in a system call, so I never get the interrupts to forward. I hacked around this by calling setitimer() in the child threads to enable the profiling timer by hand. (Yes, I understand how information can be lost both with mcount() and with the profiling timer in the presence of multiple threads. But any information is better than none, which is what you get from gprof right now for everything but the main thread.)
andrea> Only userspace calls mcount() so only userspace will be andrea> profiled.
mcount() generates the call graph; I am talking about the statistical sampling provided by the profiling timer. I understand why system calls are not sampled, but I am not sure I like it. High-latency system calls can have a big effect on an application's performance. If your application is slow because it makes too many slow system calls, there does not seem to be any easy way to find that out; the results of gprof can even be misleading.
- Pat
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |