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

ZramMeter: update bar mode #1217

Merged
merged 3 commits into from
Apr 11, 2023
Merged

ZramMeter: update bar mode #1217

merged 3 commits into from
Apr 11, 2023

Conversation

cgzones
Copy link
Member

@cgzones cgzones commented Apr 3, 2023

Show both compressed and uncompressed bars.

Closes: #1216

Copy link
Member

@BenBE BenBE left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@BenBE BenBE added enhancement Extension or improvement to existing feature Linux 🐧 Linux related issues labels Apr 3, 2023
@BenBE BenBE added this to the 3.3.0 milestone Apr 3, 2023
Useful for bar mode if latter values of the meter comprise previous
ones.
Copy link
Member

@BenBE BenBE left a 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 …

CRT.c Outdated Show resolved Hide resolved
Show both compressed and uncompressed bars.

Closes: htop-dev#1216
@BenBE BenBE merged commit 467bb78 into htop-dev:main Apr 11, 2023
@cgzones cgzones deleted the zram_meter branch April 12, 2023 17:16
@Explorer09
Copy link
Contributor

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?)

@BenBE
Copy link
Member

BenBE commented Aug 24, 2023

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.

@Explorer09
Copy link
Contributor

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?

@BenBE
Copy link
Member

BenBE commented Aug 25, 2023

Just clamping should suffice IMO. Only add color if that's more or less for free in the existing code …

@Explorer09
Copy link
Contributor

I made pull request #1286 as a follow-up of this.

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 Linux 🐧 Linux related issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Zram bar shows compressed value instead of uncompressed value
3 participants