* [9fans] kprof
@ 2002-04-21 16:30 andrey mirtchovski
0 siblings, 0 replies; 6+ messages in thread
From: andrey mirtchovski @ 2002-04-21 16:30 UTC (permalink / raw)
To: 9fans
i'm trying to modify kprof to provide a syscall tree the same way
'prof -d' does, but i can't figure out how to handle the data
accumulated in devkprof.c's _kproftimer().
i understand the current way it works -- storing the total time the
kernel has spent in a certain function, but what i can't figure out is
how to store the actual PC values for the entire timespan between a
start and a stop command.
one way is to create a (presumably large!) array and incrementally
store the current PC value at each call to _kproftimer(), but is that
a decent solution? am i right in assuming (based on observations :)
that no syscall can be executed in _kproftimer()?
andrey
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] kprof
@ 2002-04-21 20:35 andrey mirtchovski
0 siblings, 0 replies; 6+ messages in thread
From: andrey mirtchovski @ 2002-04-21 20:35 UTC (permalink / raw)
To: 9fans
i managed to do something like what i wanted by modifying devkprof.c
like:
allocate 10mins * 60 secs * 1000ms for storing the pc, then at each
call store the pc value passed to _kproftimer() in the array. (so, it
only works for 10 minutes, which is plenty enough for what we're
looking at)
then the kprof executable prints out the corresponding function name
assiciated with this pc...
here's how the final output looks like (note, i piped it uniq to avoid
crud):
.....
01ced i8259isr
46a8e v6tov4
00301 halt
5fac0 runproc
00301 halt
01ced i8259isr
00301 halt
01ced i8259isr
00301 halt
5c35b seg
00301 halt
01ced i8259isr
00301 halt
5f8d0 runproc
00301 halt
69f21 ilock
00301 halt
01ced i8259isr
6edd2 poolfree
00301 halt
0a75d transmit
.....
unfortunately it's not as good as prof -d, but paired with the normal
kprof output some information could be gleaned from it.
if anyone needs the diffs, mail me privately
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] kprof
@ 2002-04-21 19:13 forsyth
0 siblings, 0 replies; 6+ messages in thread
From: forsyth @ 2002-04-21 19:13 UTC (permalink / raw)
To: 9fans
>>charged 4%. Chances are against you that this way of accounting will
>>give you the correct answer.
there was a paper explaining how the original version of gprof
gave misleading answers. i think it was in Software: P & E
but i'm not sure. the usual net search engines will probably know.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] kprof
@ 2002-04-21 16:53 rob pike, esq.
0 siblings, 0 replies; 6+ messages in thread
From: rob pike, esq. @ 2002-04-21 16:53 UTC (permalink / raw)
To: 9fans
_kproftimer is called from the clock routine.
You're proposing the gprof approach, where you notice 12% of the time
is spent in a routine, which is called in 3 places, so each place gets
charged 4%. Chances are against you that this way of accounting will
give you the correct answer.
-rob
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] kprof
@ 2002-04-21 16:51 andrey mirtchovski
0 siblings, 0 replies; 6+ messages in thread
From: andrey mirtchovski @ 2002-04-21 16:51 UTC (permalink / raw)
To: 9fans
how about just keeping track of the pc at each call to _kprofinit()
and then translating that into functions the pc is at off-line? it's
not a general solution, will have gaps and will not be fine-grained
but at least it'll give us an idea (hopefully) where a memmove() is
called from, if the kernel spends 5% of its time there...
how often does _kproftimer() get called? i'll have to dig deeper...
andrey
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] kprof
@ 2002-04-21 16:41 rob pike, esq.
0 siblings, 0 replies; 6+ messages in thread
From: rob pike, esq. @ 2002-04-21 16:41 UTC (permalink / raw)
To: 9fans
Prof -d works by rewriting the text of the program to include
statistics-gathering code at each function call/return. Without
such code at function points in the kernel, kprof -d cannot work.
However, you'll have an awful time managing that statistics-
gathering code in a running kernel with interrupts and such
going on. Yikes.
-rob
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-04-21 20:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-21 16:30 [9fans] kprof andrey mirtchovski
2002-04-21 16:41 rob pike, esq.
2002-04-21 16:51 andrey mirtchovski
2002-04-21 16:53 rob pike, esq.
2002-04-21 19:13 forsyth
2002-04-21 20:35 andrey mirtchovski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).