On 2021-01-25 12:09, Chris wrote:
On 2021-01-25 11:52, Chris wrote:
On 2021-01-24 23:10, Joshua M. Clulow via openindiana-discuss wrote:
On Sun, 24 Jan 2021 at 21:13, Chris <[email protected]> wrote:
On 2021-01-24 18:53, Chris wrote:
> On 2021-01-24 17:48, Joshua M. Clulow via openindiana-discuss wrote:
>> On Sun, 24 Jan 2021 at 17:27, Chris <[email protected]> wrote:
> All the reports I've seen thus far, indicate 800x600.
> You're suggestion confirms it:
> ts_p_dimension = {
> ts_p_dimension.width = 0t800
> ts_p_dimension.height = 0t600
> }
> ts_pdepth = 0t32
Based on that, I don't imagine trying to drop the resolution is really
going to help.
> I'm booting via BIOS. While the CPU may be involved. I would have
> imagined that the cycles would be on the GPU. Which should be more than
> adequate to run high frame rates.
With the current framebuffer console code we have, I believe we
basically map a region of the video RAM into the host physical address
space. The terminal emulator in the kernel which runs on the CPU just
copies pixels (bytes, really) from the region in memory where we store
the font into the right place in the mapped region to make it all show
up on the screen. I don't believe the GPU is really being used for
anything, at least directly.
Does this system support UEFI booting as well? It may help to get the
entire contents of the "tems" object to get us more detail about
exactly how the console is set up; e.g.,
# mdb -ke 'tems::print -d'
Attached as mdb-ke
> Thank you *very* much for taking the time to reply!
You are most welcome!
> I'll dump some mpstat data to file, and see what (if anything) pops up,
> and report what it contains.
I have taken a look at your mpstat output, and it does indeed seem
like between ~09:02:23PM and ~09:02:44PM (a period of around 20
seconds) one CPU was spending 100% of its time executing kernel code
(the "sys" column). This matches up with the ~20 seconds of sys time
(the 23.223s) in the output of "time ls" you also posted.
As it seems this is pretty reproducible, the next thing I would do is
figure out what we're doing in the kernel for that 20 seconds. You'll
want to use DTrace to capture kernel stacks; e.g.,
# dtrace -x stackframes=100 -n '
profile-997 /arg0/ { @[stack()] = count(); }
tick-60s { exit(0); }' -o out.kern_stacks
OK I simply created an sh script (DTTRACE) with the contents above and
fired it off as; sudo ./DTRACE &
followed by; ls -Cla /usr/include
which created: out.kern_stacks (attached).
That will capture the stack of what's running in the kernel (if the
kernel is running at the time) on each CPU, 997 times per second, for
60 seconds. While that's running, kick off the "time ls" again. Take
the "out.kern_stacks" file and pass it through the flame graph
generator; e.g., something like:
$ ./stackcollapse.pl out.kern_stacks | ./flamegraph.pl > output.svg
The results of the above are attached as: out_kern_stacks.svg
I has somehow expected a longer spike on the graph, as the output of
ls -Cla /usr/include took the same ~20 seconds to finish writing to the
screen as before.
OK the list stripped the flamegraph file attached. So I'm attaching it as:
out_kern_stacks_svg.txt
in hopes it makes it through.
Nope. The list ate that one too.
let's try:
https://sunos.info/out_kern_stacks_svg instead. :-)
HTH
Thanks again! :-)
--Chris
Thank you very much all your helpful advice!
--Chris
You can open "output.svg" in a web browser and inspect the aggregated
view of all the stacks. It'll probably be small enough to attach to
an e-mail here.
Note, the perl scripts above, and more detailed instructions, are all
up on GitHub:
https://github.com/brendangregg/FlameGraph#dtrace
Cheers.
--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX
_______________________________________________
openindiana-discuss mailing list
[email protected]
https://openindiana.org/mailman/listinfo/openindiana-discuss
