OSDev.org

The Place to Start for Operating System Developers
It is currently Sun Nov 19, 2017 3:30 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: debugging and benchmarking an OS
PostPosted: Fri May 28, 2004 4:37 am 
hi,
What are the best ways of debugging and benchmarking an OS.
For debugging, We can use simple screen printing. Something more useful and advanced.
For benchmarking, we can use two time() functions to get the total time taken by a syscall (say). Some thing more ???
Can we use existing debuggers to debug an os. I tried gdb but segmentation fault. Of course, it tries to run the executable which contains ring 0 operations .
thanks


Top
  
 
 Post subject: Re:debugging and benchmarking an OS
PostPosted: Fri May 28, 2004 5:05 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7137
Location: Germany
Debugging:

Bochs provides an out port for debugging, i.e. your kernel can print debug messages when running under Bochs.

No, you can't use gdb as such, since gdb requires to run its executable under control - but in kernel space, the only code "in control" is the kernel itself. (Someone has to handle gdb's output et al, right?) Hence the segfault you encountered.

However, gdb provides a feature called "serial debugging", i.e. using machine A to debug machine B - and if you add such a serial interface to your kernel, you can use gdb on A to debug the kernel on B.

As for profiling (which is the correct terminus technicus, benchmarking is for CPUs), later generations of the IA32 family provide dedicated registers for this. I don't have the Intel manuals at hand but will look it up if no-one has filled in the blank by the time I get home for the long weekend. ;-)

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re:debugging and benchmarking an OS
PostPosted: Fri May 28, 2004 6:05 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 2:31 am
Posts: 5959
Location: In a galaxy, far, far away
true. Those registers (the MachineSpecificRegisters) will for instance tell you how many cache misses, memory read/write cycles, etc. occured. The 'TimeStampCounter' is one of them and will tell you the amount of CPU cycles elapsed since the PC is on (iirc), which will offer a far more accurate timing that any time() function could do :)

If someone has a pointer to a tutorial about serial debugging (what cable should be set up, what code should be present in the kernel to support it, etc), it would be welcome in the FAQ, even if it's for a legacy OS (linux ?)

_________________
Image May the source be with you.


Top
 Profile  
 
 Post subject: Re:debugging and benchmarking an OS
PostPosted: Fri May 28, 2004 6:18 am 
Offline
Member
Member
User avatar

Joined: Tue Oct 17, 2006 11:33 pm
Posts: 3860
Location: Eindhoven
virusx wrote:
hi,
What are the best ways of debugging and benchmarking an OS.
For debugging, We can use simple screen printing. Something more useful and advanced.
For benchmarking, we can use two time() functions to get the total time taken by a syscall (say). Some thing more ???
Can we use existing debuggers to debug an os. I tried gdb but segmentation fault. Of course, it tries to run the executable which contains ring 0 operations .
thanks



For noninterruptible system calls there's a simple way to determine how much time they take, and how often they're called. Create an array of those functions, and upon entering the function, you increase the call count by one, and substract the current RDTSC from the time-taken value. Upon exit, you add the current RDTSC to the time-taken value.

After a while, the time taken divided by the call count is going to stabilize, and tells you how long it takes on average. The call count indicates how often it's called in the time stretch you've viewed.

For functions that can block, you could store the current-func-number somewhere, and then when the block-thread funciton is called, you add the current, when it's resumed you substract the current... etc :)

Note that this is a monolithic technique and very probably isn't translatable to microkernels. Still, for monolithic ones it gives a nice approximation of the call duration and where most of the time is spent.


Using this info you can then draw a graph displaying the amount of time taken in some function in total, and see which functions take most time. Optimize either the function itself or the amount of calls to the function (in functions calling this one). This way, reduce all things that take a significant amount of time. There you go, major speedup.


Top
 Profile  
 
 Post subject: Re:debugging and benchmarking an OS
PostPosted: Fri May 28, 2004 6:29 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7137
Location: Germany
@ Pype:

FAQ about kernel debugging (Linux centric but has good info, on remote debugging too):

http://www.kernelhacking.org/docs/kerne ... exs09.html

You will also want to read (at least) chapter 17 of the gdb manual.

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re:debugging and benchmarking an OS
PostPosted: Sat May 29, 2004 9:18 pm 
hi,
For performence monitering we have rdpmc instruction(Intel pentium ). No problem on that. It gives us no of cache miss, tlb miss and much more than i can think of.
As for gdb, I will read and ask further.

Also blocking system calls harder to measure.

Thanks.


Top
  
 
 Post subject: Re:debugging and benchmarking an OS
PostPosted: Tue Jun 01, 2004 1:58 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 2:31 am
Posts: 5959
Location: In a galaxy, far, far away
virusx wrote:
Also blocking system calls harder to measure.


simply substract rdtsc() to the task->syscall[sysno] on cpu_release() by the scheduler ?

_________________
Image May the source be with you.


Top
 Profile  
 
 Post subject: Re:debugging and benchmarking an OS
PostPosted: Tue Jun 01, 2004 2:24 am 
Offline
Member
Member
User avatar

Joined: Tue Oct 17, 2006 11:33 pm
Posts: 3860
Location: Eindhoven
Pype.Clicker wrote:
simply substract rdtsc() to the task->syscall[sysno] on cpu_release() by the scheduler ?


yes and no. You must do that on both release and acquiring, for all syscalls. It requires more infrastructure and requires you to use a table with overflow guarding. Possibly use 128-bit integers for really fast machines with N processors where N is a large number.

guess what my previous post said?

*is off to make a performance module for his own OS*


Top
 Profile  
 
 Post subject: Re:debugging and benchmarking an OS
PostPosted: Tue Jun 01, 2004 3:23 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 2:31 am
Posts: 5959
Location: In a galaxy, far, far away
Candy wrote:
It requires more infrastructure and requires you to use a table with overflow guarding.

Hmm ... i guess i saw your point. If several processors add the 'TSC' together when its value is using the whole 64 bits, we could end with a situation where the 'start values' added by those processors goes over the 64 bits and thus computation results may get wrong.

right ?

Alternatively, one could use the JVM method of taking a snapshot of the stack trace at each timer IRQ, and telling the 'usage' of a function by the amount of time it reappears in the stack trace ...

This will, however, require your kernel to have a eip->functionID resolver datastructure to work, but it doesn't require you to alter the monitored code...

_________________
Image May the source be with you.


Top
 Profile  
 
 Post subject: Re:debugging and benchmarking an OS
PostPosted: Wed Jun 02, 2004 1:03 am 
Offline
Member
Member
User avatar

Joined: Tue Oct 17, 2006 11:33 pm
Posts: 3860
Location: Eindhoven
Pype.Clicker wrote:
Candy wrote:
It requires more infrastructure and requires you to use a table with overflow guarding.

Hmm ... i guess i saw your point. If several processors add the 'TSC' together when its value is using the whole 64 bits, we could end with a situation where the 'start values' added by those processors goes over the 64 bits and thus computation results may get wrong.

right ?

Was the idea, but with proper mutexed code that won't happen. Never mind that comment.
Quote:
Alternatively, one could use the JVM method of taking a snapshot of the stack trace at each timer IRQ, and telling the 'usage' of a function by the amount of time it reappears in the stack trace ...

This will, however, require your kernel to have a eip->functionID resolver datastructure to work, but it doesn't require you to alter the monitored code...

That's yucky. Not only does it give an estimate, it gives a bad estimate. Take IO bound functions, they're pretty likely to be on the stack, so you'd go optimize them only to find that they actually didn't take any time. It's reliable in all identical threads, but really bad in mixed type operations, such as FS translation and HD access.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], Google [Bot], sleephacker, Yahoo [Bot] and 17 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group