colonel / News: Recent posts

I did some large commits that implemented scheduler activations and removed most of the synchronous ipc stuff. This also means that almost no userspace programs work as expected (yes still does it's job *g*). The next thing to do would be to implement the new ipc path.

However, this probably won't happen. I'm giving up colonel in favor of very similar but more ambitious yet-to-be-disclosed project.

The capas transition is finished. I finshed the fastpath adaption and just uploaded a new demofloppy. Surprisingly, the measured overhead (bpong) is less than 10 cycles.

I have created a "colonel-baseline" tag. This marks the border to a new phase in kernel development, I'll now start to realize stuff from FUTURE_PLANS. The first is the transition to a memory-to-memory design for capabilities, i.e. the introduction of a capability address space (actually there is one shared as).

I decided to change all license blobs to say gplv3 or any later version. Of course the old files in svn are still gplv2+, but any new changes will not be available as gplv2.
Also I implemented a fully functional ipc fastpath. It does neither slow down servers that accept strings nor drivers.

I have just merged the branch of the eight steps plan to fastpath2 into trunk. Null rpc time is now down to <260 cycles, pistachio/amd64 is about 230 cycles.

I have finally managed to buy and set up my new test hardware, so new optimizations can be expected again. I first cleaned and sped up the syscall stub, the fast ipc path is now some 370 cycles, which is some 140 cycles slower than pistachio still. I will concentrate on rewriting and optimizing the fastpath now. I have a plan of eight (sometimes relatively coarse grained) steps here to do this, and I hope very much that this will give an enormous performance boost.
Btw, I uploaded a new demofloppy that incorporates the improved syscall stub.
Oh, and I tested (and fixed) the serial console output driver.

I managed to create a bootable pistachio benchmark. It is really twice as fast as colonel :(.

I checked in the ipc fastpath implementation and uploaded a new demo floppy. On my box the fastpath doubled the ipc performance, it is currently down to some 400 cycles. Pistachio/amd64 reports ipc permformance that is about twice that fast, but I'm not sure to what extent these values are comparable (they were taken on different machines). I would love to performe a measurement of pistachio ipc speed myself, to get values that are definitely comparable, but I could not yet manage to create a bootable floppy of pistachio..

Thanks to the help of the guys in #qemu I was finally able to track down the nop #ud exception to qemu 0.8 not supporting multibyte nop. This should be fixed in 0.9. I added makefile code to disable optimizations conditionally. I uploaded a new demo floppy that has special qemu boot entries.

I have lastly made colonel run on real hardware (there was an issue with interrupts being enabled too early and with spurious interrupts).
Sadly I only have one machine, and as I'm not eager to reboot often (or to e.g. shred my hd in worst case), this took some time (I noly fixed things the day and then tested after shutting down), and I will not test on hardware more than once a day, and probably not before committing. If you by chance have a spare machine to donate, feel free to send me a mail ;).
Of course the fact that it's working on my machine doesn't mean it's bug free, so please test and report any bugs to me (by mail).
As another point, I get some strange invalid opcode errors when running optimized userland in qemu (basically I always get them when "nopl 0x0" or similar is executed). I don't get them on the real hardware, though. Most boot entries are duplicated therefore, once with an optimized version of samekh0 one once with an unoptimized version.

After checking in bpong, a version of pong optimized for speed, and the beginning of the c version of the ipc fast path, I decided to upload a new version of the demo floppy so you can run the benchmarks yourself. Please note that this benchmark is more proof of concept than proof of speed, ipc is still (and probably will some time be) extremely slow (I think about one order of magnitude slower than l4).

In case you didn't notice, an early demo floppy is available in the downloads section.