Opened 6 years ago

Last modified 4 years ago

#697 new defect

Kernel console is painfully slow on Freerunner

Reported by: Jiri Svoboda Owned by:
Priority: major Milestone:
Component: helenos/unspecified Version: mainline
Keywords: ui Cc:
Blocker for: Depends on:
See also:


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.

Change History (7)

comment:1 by Jakub Jermář, 6 years ago

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.

comment:2 by Jakub Jermář, 6 years ago

Milestone: 0.7.1

comment:3 by Jiri Svoboda, 6 years ago

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.

comment:4 by Jiri Svoboda, 5 years ago

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

revno: 2090
committer: Martin Decky <>
branch nick: HelenOS.mainline
timestamp: Mon 2014-03-17 16:00:13 +0100
  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.

comment:5 by Jiri Svoboda, 5 years ago

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.

comment:6 by Jiri Svoboda, 5 years ago

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…

comment:7 by Jiri Svoboda, 4 years ago

Keywords: ui added
Note: See TracTickets for help on using tickets.