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