http://e-mind.com/~andrea/patch_ikd_arca.shtml
ftp://e-mind.com/pub/linux/patch-ikd-arca/
You need to enable the kernel debugging option in the menuconfig. Then you
need to set to Y the kernel tracer and the profiler. Say Y also in the
tracing option of TIMESTAMPS (not truncated timestamps though) and to the
TRACE_PID. Eventually (better) also TRACE_CPU but I never run the
patch-ikd on a SMP machine so I don' t know if it would work at all btw
;-). So (tips) if you get problem with my latest patch try to compile the
kernel UP and will work for sure (at least on 2.1.120). Leave the size of
the trace as it' s default (or eventually more if you can' t find a
cyclic trace report).
You need to compile every part of the kernel loaded at ./prog1 running
time, in the kenrel. It has not to be compiled as module to semplify the
generation of the System.map.
You also need to run `make debug` after the kernel got compiled. This way
you will compile the ktrace proggy.
Then boot the kernel with profile=4 in the cmdline from lilo shell or
lilo.conf append rules.
Then run ktrace -m whereis/System.map -s 233 >/tmp/trace-OK (if 233mhz)
while the first istance of prog1 is running. You should see cycles in the
trace if you look at it. Then do the mess and reproduce the overruns and
the slowdown. Then run again only one istance of prog1 that is not working
well at this time and at the same time run again ktrace ...
It' s very important that you will everything in your system except init,
update, 1 bash and gettyes at ktrace run time to decrease the mess in the
trace output (to log only what we are interested).
The two traces will should everything we need to debug and fix your
problem that I can' t reproduce here btw.
./a.andrea@dragon:~$ ./a.out
init
150 iterations in 14.961314 seconds with 0 overruns
150 iterations in 15.000563 seconds with 0 overruns
150 iterations in 15.000661 seconds with 11 overruns
150 iterations in 15.000585 seconds with 1 overruns
150 iterations in 15.106852 seconds with 10 overruns
150 iterations in 14.994293 seconds with 1 overruns
150 iterations in 15.000598 seconds with 5 overruns
150 iterations in 15.001685 seconds with 0 overruns
150 iterations in 15.099449 seconds with 16 overruns
150 iterations in 15.009805 seconds with 0 overruns
150 iterations in 14.991363 seconds with 1 overruns
150 iterations in 15.013703 seconds with 0 overruns
150 iterations in 14.987951 seconds with 2 overruns
150 iterations in 15.000083 seconds with 1 overruns
150 iterations in 15.000564 seconds with 4 overruns
150 iterations in 15.000733 seconds with 0 overruns
150 iterations in 15.008320 seconds with 1 overruns
150 iterations in 14.992646 seconds with 1 overruns
150 iterations in 15.000582 seconds with 1 overruns
150 iterations in 15.000810 seconds with 0 overruns
150 iterations in 15.000378 seconds with 2 overruns
150 iterations in 15.014403 seconds with 0 overruns
150 iterations in 32.620487 seconds with 105 overruns
here I started 4/5 other process on the other tty.
150 iterations in 66.112259 seconds with 367 overruns
150 iterations in 66.276924 seconds with 366 overruns
150 iterations in 66.003899 seconds with 354 overruns
150 iterations in 67.770706 seconds with 406 overruns
150 iterations in 67.875923 seconds with 420 overruns
150 iterations in 67.063744 seconds with 431 overruns
150 iterations in 69.050720 seconds with 426 overruns
150 iterations in 68.475510 seconds with 443 overruns
150 iterations in 41.469368 seconds with 243 overruns
150 iterations in 15.001595 seconds with 2 overruns
150 iterations in 15.004775 seconds with 1 overruns
150 iterations in 15.004775 seconds with 1 overruns
150 iterations in 14.985401 seconds with 2 overruns
Bench terminated.
andrea@dragon:~$ ./a.out
init
150 iterations in 15.003782 seconds with 2 overruns
150 iterations in 15.012808 seconds with 1 overruns
Bench terminated.
There is a printing in the background so I expect that if the system would
be idle _as_ when I started the proggy I should read again 14.985401 with
0 overruns.
After you have logged the two traces you can use readprofile (you' ll find
it at sunsite.unc.edu) to read the profiling info. So run readprofile
--map (or something similar) System.map (sysmap of the ikd compiled
kernel). Then send me the output compressed again. Then run `echo 1
>/proc/readprofile`, run one istance of the proggy again and send the the
second readprofile output. The profiling is not very important (it does
not allow to understand what' s going wrong for you), is just that I am
courious to see it ;-).
Andrea[s] Arcangeli
-
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/faq.html