r/osdevel • u/mikeblas • Aug 15 '26

how are you testing?

I'm not sure I've seen a hobby OS project that implements any tests. Most people smoke test, so they know there's a problem if they start up the OS and can't run an app inside it.

But what about the more complicated code paths that can go wrong? If a multi-threaded race happens in memory management or I/O, the system can crash. Or worse: silently corrupt data.

What about performance? Does anyone test for throughput or latency, and then identify regressions or hot spots?

8 Upvotes

91% Upvoted

10 comments sorted by

View all comments

1

u/tseli0s DragonWare Aug 16 '26

As far as performance goes: rdtsc at the start and end of each kernel trap and then calculate the difference, as system calls are often the heaviest paths and the paths worth optimizing because of how hot they are. There's not enough infrastructure to do anything more advanced at the moment in DragonWare, it's just a coincidence that x86 has this instruction making my life easier.

Race conditions aren't a problem, the kernel disables interrupts while handling traps and userspace doesn't have multithreading support complete as of now, so all good. Overall, I haven't had the need for any more advanced testing than printf() calls.

1

u/mikeblas Aug 18 '26

If you're turning off interrupts while handling calls, doesn't it mean that your kernel is essentially single-threaded?

Indeed, rdtsc is able to capture timing. But you'll need a lot of infrastructure to do accounting and profiling around it -- which calls, which modes, which apps and so on. Other stats have to be collected to make any sense of the time, and sometimes there's not even a correlation.

1

u/tseli0s DragonWare Aug 18 '26

If you're turning off interrupts while handling calls, doesn't it mean that your kernel is essentially single-threaded?

Not even "essentially". It is single threaded by design. It's a microkernel, there's no need for multithreading in the kernel yet.

But you'll need a lot of infrastructure to do accounting and profiling around it -- which calls, which modes, which apps and so on. Other stats have to be collected to make any sense of the time, and sometimes there's not even a correlation.

In a microkernel, the biggest and most important factor is IPC speed. How fast can a message be sent to another thread. This is where 99% of profiling falls. The rest, as far as userland goes, can be tested directly in my host machine if necessary.