Messages in this thread | | | Date | Sun, 9 Jun 1996 12:32:58 -0400 (EDT) | From | Ingo Molnar <> | Subject | Problem: __inline__ functions in the kernel & cli()/sti() latency measurement |
| |
what is the point of using __inline__ functions ...
__inline__ void foo( arg ) { int i; do something; do another thing; }
why not:
#define foo( arg ) { \ int i; \ do something; \ do another thing; \ }
[ ok, inlining can be turned on and off, thus tuning the kernel ... but why are they in include files ... like sched.h or skbuff.h ... ]
my problem with __inline__ functions is that for example, if they are defined in include files, and i use __FILE__, then i get ugly names like "/usr/src/linux/include/asm/system.h", or similar. And it's hard to identify where the actual inlined function is. ie. if i do prink(...__FILE__ .. __LINE__) debugging then i get ugly output and dont really know from where the inlined functions were called. (and __builtin_return_address(n) cant be used cleanly in my case, as explained later).
I'm coding a cli()/sti() latency runtime-measurement wrapper to the cli(),sti() macros in system.h, and the current /proc output is:
[...] (dev.c,747)-(dev.c,764): 71.28 (dev.c,597)-(irq.c,365): 63.90 (dev.c,597)-(dev.c,600): 59.53 (/home/mingo/linux/linux/include/linux/sched.h,438)-(irq.c,365): 18.03 (/home/mingo/linux/linux/include/linux/sched.h,438)-(softirq.c,39): 44.05 (/home/mingo/linux/linux/include/linux/sched.h,438)-(/home/mingo/linux/linux/include/linux/sched.h,4(/home/mingo/linux/linux/include/linux/sched.h,418)-(/home/mingo/linux/linux/include/linux/sched.h,4(/home/mingo/linux/linux/include/linux/sched.h,438)-(/home/mingo/linux/linux/include/linux/sched.h,4(vga.c,376)-(vga.c,392): 72.67 (vga.c,422)-(irq.c,365): 46.35 (vga.c,422)-(softirq.c,39): 59.75 (vga.c,422)-(vga.c,458): 73.78 (ide.c,805)-(ide.c,811): 61.76 (ide.c,2017)-(ide.c,2049): 53.77 (ide.c,2059)-(ide.c,2066): 54.07 (/home/mingo/linux/linux/include/linux/sched.h,418)-(/home/mingo/linux/linux/include/linux/sched.h,4(ll_rw_blk.c,162)-(ll_rw_blk.c,164): 73.60 (/home/mingo/linux/linux/include/linux/sched.h,438)-(/home/mingo/linux/linux/include/linux/sched.h,4(serial.c,921)-(serial.c,1214): 206.58 (serial.c,921)-(serial.c,925): 99.61 (serial.c,1212)-(serial.c,1214): 2.13 [...]
apart from the __inline__ functions in sched.h, the output looks pretty. the output format is: "(cli:file,line)-(sti:file-line):max_latency_so_far" (latency unit is microseconds)
i'd like to get rid of those long and hard to identify lines.
i couldnt integrate __builtin_return_address(n) and friends into the concept, i think __FILE__ and __LINE__ is the best thing to do. (and it's human readable as well). Or should i use absolute addresses like the kernel profiler, and decode them later? [it looks much harder to code it than the __FILE__, __LINE__ approach].
Requirement is that i can't touch the original cli()-s and sti()-s and restore_flags() in the sources, thus for example i cant distinguish from where cli() was called: an inlined function or something else.
all comments welcome,
Ingo
| |