Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Writing to the framebuffer is slow on bare metal #401

Open
daniel-keitel opened this issue Nov 11, 2023 · 2 comments
Open

Writing to the framebuffer is slow on bare metal #401

daniel-keitel opened this issue Nov 11, 2023 · 2 comments

Comments

@daniel-keitel
Copy link

Writing to the framebuffer is extremely slow on bare metal.
Setting the caching behavior of the framebuffer to write combining results in significantly higher throughput.

The framebuffer should either be setup to use write combining in the bootloader,
or it should be mentioned in the readme/migration guides.

(It took me quite some time to figure out that that was my bottle neck)

@phil-opp
Copy link
Member

Yes, setting the cache to write combining improvies the performance considerably. Mentioning it in the README and migration guide is a good idea!

I also thought about setting it by default for the framebuffer memory region, but I'm not sure how yet. The PAT seems like the more modern approach, but it requires modifying the default config to enable write-combining caching, which might lead to issues if the kernel changes it later. MTRRs seems to be the legacy way to do it, but I haven't had time to take a coser look.

What approach did you use for your kernel?

@daniel-keitel
Copy link
Author

I changed the PAT entry for write_through + cache_disabled (index 3) to write combining; And changed the page table flags of the framebuffer to use this entry. This is no option for the bootloader since the user doesn't expect this behavior.

A better approach would be to make use of the third bit to address the pat.
This, as far as I know, requires the framebuffer to be mapped in huge pages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants