-
-
Notifications
You must be signed in to change notification settings - Fork 440
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
ZramMeter: update bar mode #1217
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Useful for bar mode if latter values of the meter comprise previous ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly LGTM. Once minor color scheme issue requiring attention …
Show both compressed and uncompressed bars. Closes: htop-dev#1216
If I mention @cgzones here would he be notified of the new post? I have a question for the ZramMeter. The ZramMeter consists of "Compressed" and "Uncompressed" values, but is it possible that a Compressed value be greater than the Uncompressed value? That is, that memory compression (or whatever it is) make the memory usage higher than the uncompressed one. How would you handle that in the bar meter drawing? (Or do you simply assume it won't happen or set "uncompress value = compressed value" if "uncompress value > compressed value" just for safety?) |
Yes, mentioning people will usually notify them. ;-) Regarding compressed > uncompressed: This is theoretically possible since due to the pigeonhole principle you must have some outputs of a compression function that are longer than its inputs. These are typically incompressible blobs of random data where the compressor can't find any redundancy to remove; thus resulting in an inefficient encoding, that takes up more space than the original data. If this happens, clamping compressed below or equal to uncompressed is a valid choice IMO; although clamping uncompressed above compressed (i.e. forcing the value up), might be an option to. I'd prefer clamping the compressed value and below uncompressed though. |
I'm thinking that if compressed > uncompressed ever happens, it's more likely an OS bug. The OS should have been able whether pages of memory are worth compressing and not try hard to compress uncompressable stuff (it would be a performance hit as well as a waste of memory). One more question: Should htop add an indication when compressed > uncompressed happens (e.g. turning the ZramMeter bar red to inform the user about the performance drop or OS bug), or is it enough to just clamp the value? |
Just clamping should suffice IMO. Only add color if that's more or less for free in the existing code … |
I made pull request #1286 as a follow-up of this. |
Show both compressed and uncompressed bars.
Closes: #1216