[OpenIndiana-discuss] How to get a usable console on OI?

[Joshua M. Clulow]

On Sun, 24 Jan 2021 at 17:27, Chris <oidev at bsdos.info> wrote:
> I have a recent install where I simply login at the
> console -- no X related stuff. Just the screen.
> Things just seem broken, For example, a simple ls /dev
> takes a full 3 to 4 seconds to fill the screen, and each
> page full is an additional 3 to 4 seconds. This is on a 3
> core AMD CPU @3Ghz && 8Gb RAM on a x16 pcie Nvidia card.
> This seems horribly unreasonable. Simple shell scripts
> that output to the screen take as long or longer to write
> to the screen. It's like the old days logging into a BBS,
> or an anonymous ftp site on an 8086 or 80286.
>
> Thanks for any clues! :-)

Do you happen to know what resolution and colour depth are in use on
the console on this machine?  As far as I recall, the current
framebuffer console code doesn't use any acceleration features, it
just writes each frame to a flat bitmap effectively.  The higher the
resolution, or the higher the colour depth, the more CPU cycles will
be spent on copying data into the display.

I believe you can tell by running something like this:

    # mdb -ke 'tems::print -d ts_p_dimension ts_pdepth'
    ts_p_dimension = {
        ts_p_dimension.width = 0t1280
        ts_p_dimension.height = 0t768
    }
    ts_pdepth = 0t32

>From these numbers we can determine the rough size of the framebuffer
data region; e.g.,

    1280 * 768 * 32 / 8 / 1024 / 1024 = 3.75 MB

If you had a larger display, say 1920x1080, that could result in
around twice as many pixels.  All things being equal, it would
probably take twice as long to draw an update.  I believe the
framebuffer modes available to you depend at least in part on what
your UEFI firmware makes available, but I'm not sure off-hand how to
enumerate them or choose between them.  Someone else may recall, or we
can look at the boot loader docs and code to find out.

With that in mind, it might help to know whether, on your system, the
CPU is the bottleneck.  Your system has a lot of cores, but is at
least one of them 100% busy (presumably mostly in the kernel) while
the display is updating?  You could run "mpstat -T d 1" redirected
into a file in the background to get overall CPU measurements with
timestamps.  Then, run something that takes 20 seconds to display and
look at the output to see if a core is busy during that time.

If there's a CPU that's relatively busy, I would next use DTrace to
profile the kernel.  You can get a flamegraph of the same 20 seconds
of busy work:

    https://github.com/brendangregg/FlameGraph#dtrace

Profiling data like that should let us know where the kernel is
spending its time, and may give pointers for optimisations or fixes we
could make.

Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org