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

Incorrect macOS RAM Usage Statistics? #1573

Open
time-killer-games opened this issue Dec 25, 2024 · 3 comments
Open

Incorrect macOS RAM Usage Statistics? #1573

time-killer-games opened this issue Dec 25, 2024 · 3 comments

Comments

@time-killer-games
Copy link
Contributor

time-killer-games commented Dec 25, 2024

I remember hearing from you all in the past that htop very intentionally calculates ram usage differently from top and also intentionally gives contradicting values between the two programs. You explained why you chose to do this but I can't remember what the reason was. Right now, how you do it is (active_count + wire_count) * page_size, as can be seen here:

mtr->values[MEMORY_METER_USED] = (double)(vm->active_count + vm->wire_count) * page_K;
I am in the process of correcting macOS ram usage for a lot of software I'm stumbling across on GitHub, because a lot of people are doing it completely wrong and honestly, imo, everyone should be doing what Apple does in their official top(1) utility. I wanted to present my solution which is how top(1) does it and see if you all would approve of the idea of me using this solution in htop like I am attempting to do for many other software.

This is what top(1) does: https://github.com/apple-opensource/top/blob/e7979606cf63270663a62cfe69f82d35cef9ba58/globalstats.c#L433-L435 Note this link is providing source code from an unofficial mirror of Apple's Open Source projects, because Apple's official source code repositories for top(1) have been taken away from public viewing. It is now closed-source I guess. It gets ram by doing (wire_count + inactive_count + active_count + compressor_page_count) * page_size. See these other pull requests I've made for more details:

If you happen to like this idea and are willing to accept my code contribution I will go ahead and make a pull request.

@time-killer-games
Copy link
Contributor Author

Some interesting points were brought up in my pull request on fastfetch we might want to consider:

fastfetch-cli/fastfetch#1463 (comment)

top(1) is a part of the single unix specification

Which specification? I didn't find that in the list of standard POSIX commands

so it is more standardized in how it calculates these types of things, and in a way that will be cross-platform

It's not standardized. There is no standard to calcuate used memory bytes. In fact, it's also hard to define what is used (and free) memory. An Apple employee said that free memory is generally a nonsense value.

Note: the free memory is not memory physically not used at all (which is the value of free_count). For example, kernel usually caches loaded files to improve performance of future use, whose memory should not be considered as used because the memory can be dropped at any time.

Linux provides the standard free memory size, called MemAvailable, which defines free memory as the amount of memory that is available for a new workload, without pushing the system into swap. I doubt the accuracy of the value. For modern system supports memory compression, as the memory usage grows, much more cold memory data can be compressed. However before compression, I don't think there is a way to know how much memory can be actually saved by compressing. Therefore, as the author of MemAvailable said, it's still an estimation.

As there is no standard to calcuate used memory, you can't say a calcuation method is wrong, as long as it make sense somehow. Even Apple programs top and activity monitor can't agree with each other. top is available on some *nix platforms doesn't mean it is right.

Also wanted you to consider my response to them:

fastfetch-cli/fastfetch#1463 (comment)

I wanted to mention, how most platforms detect free memory is very different from how macOS does it and their official API's for doing this do in fact match what top shows for free memory even though macOS does not. As a result of most people using the official API's for this on their systems, programs like Godot, Redot, and even fastfetch are reporting the same thing for free memory that top is showing for unused memory on all platforms except macOS, I know this from my own testing. So I would say it would be better if macOS were consistent with other platforms and matched what top shows for unused memory. I even tested recently what fastfetch does on more obscure platforms like Solaris/illumos and it shows the same thing top does. Same also goes for used memory, most platforms besides macOS all these software are matching what top is showing.

I'll leave it up to you all if this approach is correct or not.

@Explorer09
Copy link
Contributor

This is likely a duplicate of #1439. Can you please review that PR and see if it matches your vision?

@time-killer-games
Copy link
Contributor Author

time-killer-games commented Dec 25, 2024

They are doing:

active + inactive + speculative + wired + compressed - purgeable - external

Which appears to be what fastfetch is doing, but fastfetch is also basing their code on the same person's repository; I would suggest doing what Apple's official top(1) program does instead. I'll reference this ticket on their pull request.

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