On 14/11/2026 20:43, Samuel Thibault wrote:
Michael Kelly, le sam. 14 nov. 2026 19:34:26 +0000, a ecrit:
I ran a really basic user-land test case using an 800x600 (32bpp) frame
buffer mapped with INTEL_PTE_NCACHE|INTEL_PTE_WTHRU.
If you disable cache, I'm not surprised that reading gets slow, because
you end up waiting for the latency of the memory for each read, rather
than reading a whole cache line.
That's how non-RAM memory is mapped by the pmap, I think, with my user
land test case. I'll re-test the read performance without the page cache
disable set.
That would be a bit tricky because you'll have to remember how print and
scroll interact etc. While, again, what would you want to actually
memmove? The application output? It does not really make sense to scroll
it since it's the gnumach output that needs to scroll, on top of the
application output.
I'm not concerned about the performance of these prints post-boot; it's
the affect on the boot time that concerns me. The boot output is much
longer on a real machine than a virtual one with lots more ACPI debug
which should perhaps be turned off ?
As mentioned in a previous mail, it looks completely ok to me to
implement scrolling by just drawing the known text of the gnumach
console at the new position, and leave the rest alone. That'll be way
faster than memmoving everything.
All gnumach printfs during and after boot are alike. A print after boot
must still scroll the gnumach content the same as during boot. This
would mean that immediately after printing one line, sometime after boot
when the Hurd console is in use, that all the previous (numrows - 1)
lines would suddenly appear too. I don't think this is acceptable.
Possibly my vision is clouded by a specific implementation that I'm
imagining.
Cheers,
Mike.
