Fork us on GitHub Follow us on Google+ Follow us on Facebook Follow us on Twitter

Opened 17 months ago

Last modified 7 weeks 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: Cc:
Blocker for: Depends on:
See also:

Description

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 (6)

comment:1 Changed 16 months ago by 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.

comment:2 Changed 16 months ago by Jakub Jermář

Milestone: 0.7.1

comment:3 Changed 16 months ago by 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.

comment:4 Changed 7 weeks ago by 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.

comment:5 Changed 7 weeks ago by 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.

comment:6 Changed 7 weeks ago by 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…

Note: See TracTickets for help on using tickets.