Fiasco built-in profiling

[Adam Lackorzynski]

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 :).
> 
> 1) 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.

> 2) 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.

> 3) 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
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/