Dear all,

let me just add to the discussion from today's online meeting that I certainly don't want to generally dismiss Jiri's claim that the redrawing of the framebuffer might cost a non-trivial fraction of the CPU time given a lot of output. The raw amount of data transferred is certainly at least one to two orders of magnitude larger compared to writing to a character output. This is also one of the reasons why the kernel benchmarks do not generate any output (contrary to the kernel tests).

However, after we optimize the drawing routines, make sure that the memory attributes are configured correctly and try to avoid other possible pitfalls, I still think that the drawing mode of the kernel framebuffer should stay event-driven. It is a debugging tool and the overhead should be reasonable for the common use case of the few logging entries. Switching to a timer-driven mode would IMHO add a lot of unnecessary complexity to the microkernel.

I can imagine that some code (e.g. tests that generate a lot of output) might even opt-in for some extra (but still conservative) optimizations such as half-page scrolling instead of line scrolling, to further lower the overhead.

In the most desperate times, we can always resort to the old tricks, such as configuring an 8-bpp framebuffer :)


Just as a single anecdotal point of reference, my non-accelerated event-driven Linux kernel console is approximately 25 times slower than the accelerated Gnome Terminal in Wayland (measured on printing random 80-character lines at the resolution of 2560x1440 and 32 bpp, same font dimensions).

The overhead of the accelerated terminal emulator is still about 70 % (compared to printing to /dev/null), despite my Wayland compositor running in a timer-driven mode at 60 Hz. Surprisingly, xterm in XWayland is about 15 % faster.

However, even the relatively slow Linux kernel console still manages to print 8000 lines per second. With, say, a 10-fold slowdown due to emulation, that is still 800 lines per second.

If the HelenOS kernel console could achieve similar throughput (and there is no reason why it couldn't), I believe it should pose absolutely no issues for the roughly 300 lines of output during the typical boot-up.


Best regards

Martin Decky

_______________________________________________
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Reply via email to