feat(memtrack): collect RSS via rss_stat and folio-rmap reconstruction

[not-matthias]

Summary

Adds RSS (resident set size) collection to memtrack, in two layers:

1. Authoritative RSS from the kernel's kmem:rss_stat tracepoint — absolute per-mm resident bytes (anon/file/shmem/swap), latest-wins.
2. Reconstructed anonymous RSS from raw kernel folio-rmap events: fentry hooks on the anon folio-rmap add/remove functions emit signed page-count deltas, so anon RSS can be rebuilt over time as Σ(add − remove) × PAGE_SIZE.

The reconstruction is a total anon RSS delta-sum, not a per-vaddr resident map — the kernel remove hook (folio_remove_rmap_ptes) carries no address, so removals can't be attributed to a vaddr (the add hooks' faulting vaddr is emitted for observability only).

Commits

• feat(memtrack): track RSS via kmem:rss_stat tracepoint — the baseline: EVENT_TYPE_RSS contract, MemtrackEventKind::Rss, parser arm, writer bench case, gated integration test.
• feat(memtrack): reconstruct anon RSS from gated folio rmap fentry hooks — EVENT_TYPE_RMAP_ANON + RmapAnon event, five fentry programs (add_new / add_ptes / remove_ptes / remove_pmd / remove_pud), CO-RE folio helpers, and the load/attach gating.
• test(memtrack): validate anon RSS reconstruction against rss_stat — ramps anon RSS via mmap/munmap and asserts the reconstructed estimate tracks the rss_stat MM_ANONPAGES peak within 25%.

What's on by default vs gated

• rss_stat tracepoint: always on. Emitting Rss events is the intended new default behavior introduced by this change — the RSS tracepoint is not gated.
• RmapAnon folio-rmap fentry programs: off by default, gated behind CODSPEED_MEMTRACK_TRACK_RMAP=1. When the flag is unset they are set_autoload(false) before load and never attached, so:
  • the skeleton still loads on any kernel (a missing fentry BTF target would otherwise fail the whole load), and
  • the folio-rmap reconstruction path stays out of production (--mode memory) and out of the existing test suites — no RmapAnon events are produced by default.

Verification

Run in a privileged, --pid=host container sharing the host kernel (7.0.12):

• Reconstruction (flag on): ✅ real anon amplitude = 64 MiB, estimated peak = 64 MiB (ratio 1.00).
• Regression (rss_tests, flag unset): ✅ passes — no RmapAnon events, folio-rmap programs stay unloaded.
• Parser unit tests, cargo fmt, and clippy clean.
• Kernel BTF signatures for all five folio_*_rmap* functions verified to match the BPF_PROG arg layouts.

Review notes (draft)

• track_command ordering: the shared test helper spawns the child before enable()/track(root_pid). In practice the child's fork→execve→ld.so→libc-init far outlasts the two BPF-map updates, so tracking is armed before the workload allocates (both fixtures captured full event streams). Flagging in case we'd prefer a leading settle-usleep in the fixtures or an enable-before-spawn change in the helper.
• PAGE_SIZE: hardcoded to 4096 (correct on x86_64). On a 16K/64K-page arm64 runner the estimate would need sysconf(_SC_PAGESIZE); rss_stat is already in bytes and unaffected. Happy to switch to sysconf if these tests run on arm64 CI.
• The chart/inspection tooling used during development lives outside the tree (dev artifact) and is not part of this PR.

[codspeed-hq]

Merging this PR will not alter performance

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

✅ 17 untouched benchmarks

---

_{Comparing cod-3089-collect-rss-in-memtrack (f6e60e6) with main (1dcc738)}

[greptile-apps]

Greptile Summary

This PR adds RSS collection to memtrack. The main changes are:

• New RSS, rmap, and lifecycle event types.
• kmem:rss_stat sampling for absolute resident counters.
• Opt-in folio-rmap hooks for reconstructed RSS deltas.
• Parser, artifact, CI, and integration-test coverage for RSS tracking.

Confidence Score: 4/5

This is close, but the optional rmap startup path should be fixed before merging.

• RSS tracepoint attachment is now handled as optional.
• The test helper changes avoid the earlier process-wide environment mutation problem.
• Opt-in rmap can still fail tracker startup on kernels where the PUD targets are not present.

Files Needing Attention: crates/memtrack/src/ebpf/memtrack/rmap.rs and crates/memtrack/src/ebpf/memtrack/tracking.rs

Important Files Changed

Filename	Overview
crates/memtrack/src/ebpf/memtrack/rmap.rs	Adds rmap support detection based on kernel version, but the PUD tier can be enabled when the actual fentry targets are unavailable.
crates/memtrack/src/ebpf/memtrack/tracking.rs	Attaches lifecycle, RSS, and rmap programs; optional PUD rmap attach errors still stop tracker startup.
crates/memtrack/tests/shared.rs	Adds RSS/rmap test helpers that pass rmap enablement directly instead of mutating process-wide environment state.

Prompt To Fix All With AI

### Issue 1
crates/memtrack/src/ebpf/memtrack/rmap.rs:54
**PUD hooks can abort startup**

This treats every 6.15+ kernel as having the PUD rmap fentry targets, but those targets depend on kernel config and architecture support. When `CODSPEED_MEMTRACK_TRACK_RMAP=1` runs on a 6.15+ kernel without the PUD pair, `CoreAndPud` keeps those programs enabled and `attach_tracepoints()` propagates the first missing-target attach error. That stops the tracker instead of falling back to the working PTE/PMD rmap hooks. Please detect the actual PUD BTF targets, or make only the PUD attaches best-effort while keeping core rmap support active.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (29): Last reviewed commit: "ci(memtrack): run bpf tests on arm and a..." | Re-trigger Greptile}

[not-matthias]

@greptileai pause reviews for now until i enable them again

[greptile-apps]

Understood — pausing reviews. I'll hold off until you re-enable them.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.

[not-matthias]

@greptileai review again, focus on the eBPF code (mostly RMAP tracking), be exhaustive

[GuillaumeLagrange]

olgtm, obviously quite a big chunk to chew, but looks mostly fine to me. Main point of concern is the maintainability of "which function can be track for which kernel version" which IMO could be improved.

[not-matthias]

@greptileai review