lkml.org 
[lkml]   [1996]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectProblem: __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



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.040 / U:25.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site