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

CPU % usage column changing width #1534

Open
DrHyde opened this issue Sep 8, 2024 · 1 comment
Open

CPU % usage column changing width #1534

DrHyde opened this issue Sep 8, 2024 · 1 comment
Labels
enhancement Extension or improvement to existing feature needs-discussion 🤔 Changes need to be discussed and require consent

Comments

@DrHyde
Copy link

DrHyde commented Sep 8, 2024

On a machine with more than 10 cores the CPU usage for an multi-threaded process can be over 1000%. htop correctly makes the column wider when this happens.

However, when that process then drops back to under 1000% the column shrinks again, and if the process is running for a long time at roughly 1000%, sometimes a bit above, sometimes a bit below, the column keeps growing and shrinking. This is visually very annoying and I think it is a bug, and that the column should always grow if needed, but never shrink - or maybe only shrink if it hasn't needed the extra space for a significant time, of the order of at least 10s of seconds.

To reproduce, try using the cpulimit tool to throttle a long ffmpeg task. For example, this will take ages to convert a 50fps video to 25fps, and attempt to use exactly 1000% of the CPU. In practice it will sometimes overshoot and undershoot, resulting in the actual osage oscillating back and forth between about 950% and 1050%:

cpulimit -l 1000 ffmpeg -y -hide_banner -loglevel error -i some-50fps-video.mp4 -scodec copy -filter:v fps=25 a-25-fps-video.mp4

You can get cpulimit here.

@BenBE BenBE added enhancement Extension or improvement to existing feature needs-discussion 🤔 Changes need to be discussed and require consent labels Sep 10, 2024
@BenBE
Copy link
Member

BenBE commented Sep 10, 2024

Resizing columns to the minimum of characters needed is actually intentional. And while this flickering in width is not the best solution, it comes with very little data that needs tracking to achieve. The implementation is actually used for quite a few more columns, and all thos columns would need to adapt a similar approach to resizing their columns to avoid creating a patchwork of solutions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Extension or improvement to existing feature needs-discussion 🤔 Changes need to be discussed and require consent
Projects
None yet
Development

No branches or pull requests

2 participants