feat(memtrack): pause producers under ring pressure

[not-matthias]

Adds opt-in, best-effort backpressure for memtrack's BPF ring buffers.

When a ring crosses its watermark, BPF latches the episode and stops the winning tracked producer. A userspace coordinator then stops the owned process tree using pidfds, drains the event, stack, mapping, and attach pipelines, clears the latch, and resumes the tree. Finite timeouts terminate the tracked tree and fail the capture; 0 remains the default and preserves drop detection, while inf waits until recovery. Detected ring loss still fails the capture.

The change also:

• lowers ring polling latency from 10 ms to 1 ms
• keeps attach/startup resume ownership coordinated with pressure pauses
• propagates the timeout through the runner's experimental memory-mode flag
• avoids x86 per-CPU private BPF stack corruption during nested uprobes by keeping hash scratch in the unpublished ring record and reducing BPF stack use

This PR is stacked on #522.

Verification

• cargo fmt --all -- --check
• cargo clippy --release -p memtrack -p codspeed-runner -- -D warnings
• Runtime tests are deferred to CI.

[codspeed]

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.

✅ 33 untouched benchmarks
⏩ 4 skipped benchmarks¹

---

_{Comparing feat/memtrack-pause-worker (31b6da1) with cod-3222-add-ebpf-based-dwarffp-unwinding (2152fe2)}

Footnotes

1. 4 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[greptile-apps]

Confidence Score: 4/5

The PR is not safe to merge until attach processing can no longer resume producers during pressure draining and the explicit Rust logging rule is satisfied.

Findings

1.  Attach Work Resumes Producers ▶
2.  Direct Stderr Logging Added ▶

Fix with agent prompt

### Issue 1
crates/memtrack/src/ebpf/attach_worker.rs:200
When an attach request is pending during a pressure episode, this barrier calls `process_batch`, whose guards unconditionally send `SIGCONT` before acknowledging completion. The pressure coordinator drains the attach worker before the event and stack pollers, so the target can resume producing events while those rings are supposed to remain quiet. Sustained allocation can refill or overflow the rings, or make finite recovery time out and kill the tracked process tree. Resume ownership must remain coordinated with the pressure pause, or the tree must be stopped and checked again after the attach barrier.

### Issue 2
crates/memtrack/tests/pressure_tests.rs:43
This test uses `eprintln!` here and again at lines 59, 62, 70, and 79. That violates the repository directive: “Never use `println!`/`eprintln!` in Rust; use tracing macros (`info!`/`debug!`/`warn!`/`error!`).” Replace these diagnostics with tracing macros; this repository requirement must be satisfied before merging.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

---

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

Summary

This PR adds opt-in memtrack ring-buffer backpressure, including a BPF pressure latch, pidfd-based process-tree suspension, timeout-bounded pipeline barriers, runner configuration, and pressure integration coverage.

• Adds 0, finite-duration, and inf timeout parsing and propagation.
• Coordinates event, stack, mapping, and attach pipeline draining during pressure episodes.
• Moves stack-hash scratch into unpublished ring records and reduces normal polling latency.
• One resume-ownership race remains between attach processing and pressure recovery.
• The new pressure test also violates the repository’s Rust logging rule.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[BPF ring crosses watermark] --> B[Latch pressure episode]
  B --> C[Pressure worker scans tracked tree]
  C --> D[SIGSTOP tracked processes]
  D --> E[Drain attach pipeline]
  E --> F[Process pending attach requests]
  F --> G[Attach guards send SIGCONT]
  G --> H[Drain event and stack rings]
  H --> I[Clear pressure latch]
  I --> J[SIGCONT owned tree]
  G -. producer may refill rings .-> H

Loading

_{Reviews (1) · Last reviewed commit: "fixup! feat(memtrack): latch ring pressu..."}

[greptile-apps]

Attach Work Resumes Producers

When an attach request is pending during a pressure episode, this barrier calls process_batch, whose guards unconditionally send SIGCONT before acknowledging completion. The pressure coordinator drains the attach worker before the event and stack pollers, so the target can resume producing events while those rings are supposed to remain quiet. Sustained allocation can refill or overflow the rings, or make finite recovery time out and kill the tracked process tree. Resume ownership must remain coordinated with the pressure pause, or the tree must be stopped and checked again after the attach barrier.

Knowledge Base Used: eBPF memory tracker

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/memtrack/src/ebpf/attach_worker.rs
Line: 200

Comment:
**Attach Work Resumes Producers**

When an attach request is pending during a pressure episode, this barrier calls `process_batch`, whose guards unconditionally send `SIGCONT` before acknowledging completion. The pressure coordinator drains the attach worker before the event and stack pollers, so the target can resume producing events while those rings are supposed to remain quiet. Sustained allocation can refill or overflow the rings, or make finite recovery time out and kill the tracked process tree. Resume ownership must remain coordinated with the pressure pause, or the tree must be stopped and checked again after the attach barrier.

**Knowledge Base Used:** [eBPF memory tracker](https://app.greptile.com/codspeed/-/custom-context/knowledge-base/codspeedhq/codspeed/-/docs/ebpf-memory-tracker.md)

---

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