net: report Darwin resident size on ibd: sizes and tip: perf - #670
Open
xstoicunicornx wants to merge 3 commits into
Open
xstoicunicornx wants to merge 3 commits into
xstoicunicornx wants to merge 3 commits into
Conversation
reardencode
requested changes
Sep 21, 2026
| /// `hwm=` peak are Linux-only. Darwin's only lifetime peak is over | ||
| /// `phys_footprint`, which excludes clean file-backed pages and so can read | ||
| /// below a mapped-file RSS — a "peak" under the current value is worse than | ||
| /// none, so it is not wired to `hwm`. |
Owner
There was a problem hiding this comment.
seems like we should rename this fn to "read_rss"
Contributor
Author
There was a problem hiding this comment.
What about ProcRss return value? Maybe should also be renamed to Rss?
Owner
There was a problem hiding this comment.
yeah - or expanding to ProcessRss, just don't want to mislead anyone into thinking it comes only from /proc when it's gonna have at least 3 different sources.
| /// none, so it is not wired to `hwm`. | ||
| pub fn read_proc_rss() -> ProcRss { | ||
| let mut out = ProcRss::default(); | ||
| if let Ok(s) = std::fs::read_to_string("/proc/self/status") { |
Owner
There was a problem hiding this comment.
probably worth gating these on cfg linux even though they're cheap.
8 tasks
read_proc_rss only read /proc/self/status and /proc/self/smaps_rollup, so on Darwin both reads missed and every memory field logged zero while the process held hundreds of MiB. Fill rss from proc_pid_rusage there. RUSAGE_INFO_V0 carries no anon/file split and no resident peak, so those fields stay zero on Darwin. The only lifetime peak available is over phys_footprint, which excludes clean file-backed pages and can read below a mapped-file RSS, so it is not wired to hwm.
read_proc_rss ran the two /proc reads on every platform and relied on the opens failing off Linux. Split it into one read_platform_rss per target so Darwin and Windows stop issuing two doomed opens on each 5s sample. fill_rss_from_status, fill_rss_from_smaps_rollup and parse_kb_field parse /proc text and now carry the same gate, as does the test covering their edge cases; they would otherwise be dead code where warnings are denied.
Proc named the Linux /proc filesystem, the wrong association now that only one of three arms goes near it. read_proc_rss becomes read_platform_rss across the two re-exports and the rbitcoin-node caller; ProcRss becomes ProcessRss. The reader takes the platform name because its mechanism really does differ per target. The struct does not: it is the same five numbers everywhere and only the count of filled fields varies, so it is named for what it holds. The wrapper that forwarded to the per-target function is gone; each arm is now the public fn itself, and its rustdoc covers only that target, since a reader on Darwin has no use for the smaps_rollup fallback. The contract they share, which fields a target can fill and that a zero often means unmeasurable rather than empty, moves to ProcessRss.
xstoicunicornx
force-pushed
the
net/darwin-rss
branch
from
September 22, 2026 21:35
6eb0a8a to
7115d1c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When rbitcoin runs on a Mac, its status logs claimed the node was using zero memory, even while it was actually holding hundreds of megabytes. The code only knew one way to ask the operating system how much memory it was using, and that way exists only on Linux. On a Mac the attempt quietly came up empty instead of reporting an error, so every memory figure in the log showed zero and anyone watching for a memory problem had nothing to watch.
This fix adds the Mac equivalent of that question, so the main memory number is now correct. A few related figures, such as the peak and the breakdown by category, still show zero on a Mac, because the system only offers those in a form that would be misleading here, and a wrong number is worse than a blank one.
Note: this is still issue on Windows.