Hi,
On Tue May 01, 2007 at 09:18:47 +0200, Stefan Scheler wrote:
I fear nobody has tried profiling in some time. Could you find out yourself what's going on and report?
Well, here we go. I meanwhile managed to get that working but encountered several problems. Especially problem 2 seems a bit odd to me. Feedback is greatly appreciated.
I'm cc'ing also Martin Pohlack, because I was told he is the man for profiling :).
- gprof wants to allocate larger junks of memory than alloc() in class
Buddy_t_base can currently handle (limit 65535 bytes). So trying to allocate larger pieces of memory, alloc() returned always 0 bytes. Increasing NUM_SIZES von 8 to 10 seems to fix this issue.
Ok, I think this is just a configuration thing.
- Next, fiasco crashes executing this line of code:
s_scale = (int)(( (float) monsize / o ) * SCALE_1_TO_1);
with the following error message:
KERNEL: Denying 0.0 to send fault message (pfa=00000008, code=00000000) to 7ff.7f
KERNEL: 0.0 (tcb=c0000000) killed: Unhandled trap
EAX 000000fe EBX 00000000 ECX f0055efe EDX 00000001 ESI 00000000 EDI 00000204 EBP c0000718 ESP c000070c EIP f000477e EFLAGS 00210282 CS 0008 SS 0010 DS 0023 ES 0023 FS 0023 GS 0023 trap 14 (Page Fault), error 00000000, from kernel mode page fault linear address 00000008
I really don't understand this one. I can execute this statement perfectly well in a separate c program on my machine (with monsize = 189784, o = 379568 and SCALE_1_TO_1 = 65536). I "fixed" this by setting s_scale manually to the calculation's result of 32768.
As Martin already said, one cannot just do floating point stuff in the kernel without special treatment. Best is to avoid it.
- The gzipped and uuencoded output thing does not produce any output
here. I didn't have the time to look into this until now. For now I disabled this and send the data in a hexadecimal encoding over the serial line.
This was buggy and has been fixed by now.
Adam