feat(memtrack): collect RSS via rss_stat and folio-rmap reconstruction#453
Open
not-matthias wants to merge 9 commits into
Open
feat(memtrack): collect RSS via rss_stat and folio-rmap reconstruction#453not-matthias wants to merge 9 commits into
not-matthias wants to merge 9 commits into
Conversation
Merging this PR will not alter performance
|
Greptile SummaryThis PR adds RSS tracking and on-demand allocator attachment to memtrack. The main changes are:
Confidence Score: 5/5This looks safe to merge.
Important Files Changed
Reviews (8): Last reviewed commit: "test(memtrack): validate RSS and rmap re..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
not-matthias
force-pushed
the
cod-3089-collect-rss-in-memtrack
branch
2 times, most recently
from
July 13, 2026 17:32
b670b0a to
2f41984
Compare
not-matthias
marked this pull request as ready for review
July 14, 2026 15:38
Comment on lines
+588
to
+590
| self.attach_task_newtask()?; | ||
| self.attach_sched_process_exec()?; | ||
| self.attach_sched_process_exit()?; |
There was a problem hiding this comment.
The rss_stat attach now warns and continues, but these new RSS lifecycle tracepoints still use ?. If a host can run the existing allocator probes but lacks or disables task:task_newtask, sched:sched_process_exec, or sched:sched_process_exit, attach_tracepoints() returns an error before the tracker starts. That keeps memory tracking unavailable on a host where only the RSS accounting side is unsupported. Make these lifecycle-only attaches best-effort as well, or gate RSS reconciliation on the lifecycle tracepoints that attach successfully.
Prompt To Fix With AI
This is a comment left during a code review.
Path: crates/memtrack/src/ebpf/memtrack.rs
Line: 588-590
Comment:
**Lifecycle attaches still abort**
The `rss_stat` attach now warns and continues, but these new RSS lifecycle tracepoints still use `?`. If a host can run the existing allocator probes but lacks or disables `task:task_newtask`, `sched:sched_process_exec`, or `sched:sched_process_exit`, `attach_tracepoints()` returns an error before the tracker starts. That keeps memory tracking unavailable on a host where only the RSS accounting side is unsupported. Make these lifecycle-only attaches best-effort as well, or gate RSS reconciliation on the lifecycle tracepoints that attach successfully.
How can I resolve this? If you propose a fix, please make it concise.
…tcher Instead of pre-attaching every allocator found on the system, a BPF fentry on security_mmap_file signals the first mapping of each unknown executable inode. A background worker stops the mapping processes, classifies the file by its symbols, attaches probes, and resumes them. This covers dlopen'd and statically linked allocators in spawned children, and skips libraries the benchmark never loads. The public API shrinks to Tracker (owns the attach worker) and Session (owns the spawned child and its event pipeline); ring buffers are polled through a generic RingBufferPoller with caller-supplied parsing. Fixes COD-1801
On-demand attach supersedes the startup scan: delete the system-wide library glob, the build-dir walk, and the CODSPEED_MEMTRACK_BINARIES env var (the runner no longer resolves exec target binaries for it). BREAKING CHANGE: CODSPEED_MEMTRACK_BINARIES is no longer read Refs COD-1801
Distro libjemalloc is built without the je_ symbol prefix, so symbol classification missed it and fell through to libc++ (jemalloc exports operator new), leaving plain malloc/aligned_alloc unprobed. Match on mallocx, which keeps its name in unprefixed builds and is unique to jemalloc.
not-matthias
force-pushed
the
cod-3089-collect-rss-in-memtrack
branch
from
July 17, 2026 14:23
41945a5 to
64688a9
Compare
Comment on lines
+737
to
+739
| self.attach_task_newtask()?; | ||
| self.attach_sched_process_exec()?; | ||
| self.attach_sched_process_exit()?; |
There was a problem hiding this comment.
These RSS lifecycle tracepoints still abort attach_tracepoints() via ?, even though rss_stat itself is best-effort. On a host where the existing allocator probes and sched_process_fork can attach but task:task_newtask, sched:sched_process_exec, or sched:sched_process_exit is unavailable or disabled, Tracker::new() fails before allocator tracking starts. These events only support RSS lifecycle reconciliation, so unsupported RSS accounting can still take down memory tracking entirely.
Suggested change
| self.attach_task_newtask()?; | |
| self.attach_sched_process_exec()?; | |
| self.attach_sched_process_exit()?; | |
| if let Err(e) = self.attach_task_newtask() { | |
| warn!("Failed to attach task_newtask tracepoint, RSS lifecycle reconciliation disabled: {e:#}"); | |
| } | |
| if let Err(e) = self.attach_sched_process_exec() { | |
| warn!("Failed to attach sched_process_exec tracepoint, RSS lifecycle reconciliation disabled: {e:#}"); | |
| } | |
| if let Err(e) = self.attach_sched_process_exit() { | |
| warn!("Failed to attach sched_process_exit tracepoint, RSS lifecycle reconciliation disabled: {e:#}"); | |
| } |
Prompt To Fix With AI
This is a comment left during a code review.
Path: crates/memtrack/src/ebpf/memtrack.rs
Line: 737-739
Comment:
**Lifecycle Attaches Still Abort**
These RSS lifecycle tracepoints still abort `attach_tracepoints()` via `?`, even though `rss_stat` itself is best-effort. On a host where the existing allocator probes and `sched_process_fork` can attach but `task:task_newtask`, `sched:sched_process_exec`, or `sched:sched_process_exit` is unavailable or disabled, `Tracker::new()` fails before allocator tracking starts. These events only support RSS lifecycle reconciliation, so unsupported RSS accounting can still take down memory tracking entirely.
```suggestion
if let Err(e) = self.attach_task_newtask() {
warn!("Failed to attach task_newtask tracepoint, RSS lifecycle reconciliation disabled: {e:#}");
}
if let Err(e) = self.attach_sched_process_exec() {
warn!("Failed to attach sched_process_exec tracepoint, RSS lifecycle reconciliation disabled: {e:#}");
}
if let Err(e) = self.attach_sched_process_exit() {
warn!("Failed to attach sched_process_exit tracepoint, RSS lifecycle reconciliation disabled: {e:#}");
}
```
How can I resolve this? If you propose a fix, please make it concise.
not-matthias
force-pushed
the
cod-3089-collect-rss-in-memtrack
branch
from
July 17, 2026 15:54
64688a9 to
b02f3cb
Compare
Sample the kernel's per-mm resident counter through the kmem:rss_stat tracepoint, emitting absolute byte values per mm member. Adds the EVENT_TYPE_RSS contract, MemtrackEventKind::Rss, the parser arm, and a writer bench case. An rss_stat update from reclaim or another process's madvise fires in the actor's context; track (mm_id, member) -> owning pid so those updates reach the owner. External events may only lower a counter, so stale reads and mm_id collisions cannot invent peaks.
Attach fentry hooks on the folio-rmap add/remove functions, emitting signed page-count deltas per MM_* bucket so anon, file, and shmem RSS can be reconstructed over time. Gated behind CODSPEED_MEMTRACK_TRACK_RMAP; the programs stay autoload-off by default so the skeleton loads on any kernel. Adds the EVENT_TYPE_RMAP contract, MemtrackEventKind::Rmap, parser arm, and bench case.
A forked child's inherited RSS is invisible to rss_stat: the fork-time counter copies fire outside the child's context, and anon COW faults are counter-neutral, so a child that only touches inherited memory never reports anything on its own. A fork event carrying the parent pid lets consumers seed the child from the parent's last absolutes; exec and exit mark where the address space is replaced or torn down.
Nine fixtures compare three per-process views - the fixture's own /proc report, rss_stat peaks, and rmap-reconstructed totals - plus an external-reclaim fixture proving out-of-context decrements reach the owner. Fork-seeded children are validated via fork_idle, whose 32 MiB is observable only through the fork-event seed. Pids are redacted and rows keep first-activity order so snapshots are stable across runs; fixtures report VmHWM instead of ru_maxrss, which survives execve and would leak the harness's peak RSS.
not-matthias
force-pushed
the
cod-3089-collect-rss-in-memtrack
branch
from
July 17, 2026 18:12
b02f3cb to
411b713
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
1 participant
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.
Summary
Adds RSS (resident set size) collection to
memtrack, in two layers:kmem:rss_stattracepoint — absolute per-mm resident bytes (anon/file/shmem/swap), latest-wins.fentryhooks 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_RSScontract,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+RmapAnonevent, fivefentryprograms (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 viammap/munmapand asserts the reconstructed estimate tracks therss_statMM_ANONPAGES peak within 25%.What's on by default vs gated
rss_stattracepoint: always on. EmittingRssevents is the intended new default behavior introduced by this change — the RSS tracepoint is not gated.RmapAnonfolio-rmapfentryprograms: off by default, gated behindCODSPEED_MEMTRACK_TRACK_RMAP=1. When the flag is unset they areset_autoload(false)before load and never attached, so:fentryBTF target would otherwise fail the whole load), and--mode memory) and out of the existing test suites — noRmapAnonevents are produced by default.Verification
Run in a privileged,
--pid=hostcontainer sharing the host kernel (7.0.12):real anon amplitude = 64 MiB, estimated peak = 64 MiB(ratio 1.00).rss_tests, flag unset): ✅ passes — noRmapAnonevents, folio-rmap programs stay unloaded.cargo fmt, andclippyclean.folio_*_rmap*functions verified to match theBPF_PROGarg layouts.Review notes (draft)
track_commandordering: the shared test helper spawns the child beforeenable()/track(root_pid). In practice the child'sfork→execve→ld.so→libc-initfar 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-usleepin 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 needsysconf(_SC_PAGESIZE);rss_statis already in bytes and unaffected. Happy to switch tosysconfif these tests run on arm64 CI.