Kernel console is painfully slow on Freerunner

[Jiri Svoboda]

As of mainline,2797, kernel console is running really slow on Neo Freerunner. The initial screen fill as well as each subsequent scroll take seconds to complete. The same was observed with release 0.7.0, but not with 0.4.3.

[Jakub Jermář]

I think this is because we run with caches disabled on armv4. IIRC, there was a brief period when we enabled caches (D-cache?, I-cache?), but then disabled it again for some reason.

[Jiri Svoboda]

Caches are just one contributor. I believe other part of the problem is that instead of doing a memmove() we re-render the characters upon scrolling. This could be fixed making scrolling in kernel console faster in general.

[Jiri Svoboda]

Kernel FB scrolling slowed down remarkably with Bazaar changeset mainline,2090

revno: 2090
committer: Martin Decky <martin@decky.cz>
branch nick: HelenOS.mainline
timestamp: Mon 2014-03-17 16:00:13 +0100
message:
  add support for framebuffer history paging (using Page Up and Page Down keys), inspiration taken from the code by Sebastian Köln
  add support for input device out-of-band signalling

So this is where the problem was introduced. It happens regardless of arch (e.g. amd64). On FreeRunner it is especially bad, but happens across arches.

[Jiri Svoboda]

I believe the main cause is that the macro BB_POS(), which is called up to three times per each character scanline, is made more complex. It had been a simple linear function, but a modulo was added. This seems to have inhibited some optimizations, leading to slowdown.

[Jiri Svoboda]

The most obvious fix is to hoist BB_POS() out of the innermost loop. I had other ideas for faster scrolling.

One idea was: why not render cell-by-cell, i.e. just use glyph_draw()? It seems though there is a reason for rendering scrolling in scanline order: to avoid artifacts, since we're rendering directly to the front buffer? If so, it should absolutely be stated in a comment in the code…

Another one: why don't just scroll the screen using a block transfer? I can't think of a good reason not to…