bench: Add memory-limited FIO benchmarks with breach detection

[yerzhan7]

Summary

Extend the existing FIO throughput benchmarks CI so that each supported workload also runs with Mountpoint built using --features mem_limiter and mounted with --max-memory-target=512 (MiB - fixed). Under this extra pressure, Mountpoint must stay within the configured budget; the new jobs surface per-test peak memory usage in a GitHub Actions step summary table so regressions/improvements in the memory limiter are easy to spot.

Non-latency only. Same FIO job definitions are used for both the regular and memory-limited variants.

• The existing bench (S3 Standard), cache-bench, and S3 Express bench jobs are extended with a strategy.matrix that fans each one out to two variants:

  • default — unchanged behaviour.
  • mem-limited — builds with --features mem_limiter, runs with S3_MAX_MEMORY_TARGET_MIB=512, and emits an extra GitHub Actions summary table.

  The matrix also drives per-variant job name suffixes, gh-pages chart sub-paths, and S3 results sub-prefixes, so the two variants don't collide.

• New .github/actions/scripts/render-mem-summary.sh that renders a Markdown table to $GITHUB_STEP_SUMMARY with per-test peak RSS, the limit, a breach flag, and peak reserved memory per area/kind. Gated on matrix.variant == 'mem-limited'.

• Shared benchmark scripts (fs_bench.sh, fs_cache_bench.sh) are now parameterised via the S3_MAX_MEMORY_TARGET_MIB env variable. When set, they:

  • Build with --features mem_limiter.
  • Mount with --max-memory-target=<N>.
  • Ask mount-s3-log-analyzer for an additional JSON file via --mem-limit-mib=<N> --extra-metrics-out=<PATH>.

  When unset, behaviour is unchanged.

• mount-s3-log-analyzer gains two optional flags, --mem-limit-mib and --extra-metrics-out, wired together with clap's requires so either both are set or neither. When both are set, the analyzer also parses Mountpoint metric log lines for:

  • mem.bytes_reserved[area=prefetch]
  • mem.bytes_reserved[area=upload]
  • pool.reserved_bytes[kind=get_object]
  • pool.reserved_bytes[kind=put_object]

  and writes JSON with the test name, peak RSS in MiB, memory limit in MiB, a `breached = peak_rss_mib

Example GitHub Actions summary

https://github.com/awslabs/mountpoint-s3/actions/runs/24720419069

| Test | Peak RSS (MiB) | Memory Limit (MiB) | Status | Peak Prefetch Reserved (MiB) | Peak Upload Reserved (MiB) | Peak Pool GetObject (MiB) | Peak Pool PutObject (MiB) |
|---|---|---|---|---|---|---|---|
| mix_1r4w | 1562.546875 | 512 | ❌ BREACHED | 32 | N/A | 32 | 1376 |
| rand_read_4t_direct | 22.0625 | 512 | ✅ OK | 68.5 | N/A | 64 | N/A |

Notes:

• Breach is non-fatal: the ❌ is informational; the CI job does not fail on a breach.
• A metric is rendered as N/A only when Mountpoint never emitted it in the logs (e.g. pool.reserved_bytes[kind=get_object] in a write-only workload). If the metric was emitted with value 0, the column shows 0.0.
• The _extra_metrics.json file is consumed only by the memory summary step. It is not fed into the gh-pages benchmark charts.

Where results are stored

Memory-limited results are stored under distinct mem_limited sub-paths so they don't collide with the existing charts:

Workload	Throughput chart path	Peak-memory chart path
S3 Standard throughput	dev/bench/mem_limited	dev/bench/mem_limited/peak_mem_usage
S3 Standard cache	dev/cache_bench/mem_limited	dev/cache_bench/mem_limited/peak_mem_usage
S3 Express One Zone throughput	dev/s3-express/bench/mem_limited	dev/s3-express/bench/mem_limited/peak_mem_usage

Why a separate _extra_metrics.json?

The existing <test>_peak_mem.json follows the {name, value, unit} schema required by benchmark-action/github-action-benchmark and feeds the gh-pages charts. Adding more fields there would pollute the charts for non-memory-limited runs. Keeping the file separate lets each consumer (benchmark-action vs. GH Actions summary) receive only what it needs.

Does this change impact existing behavior?

No - adding new benchmarks only.

Does this change need a changelog entry? Does it require a version change?

No.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and I agree to the terms of the Developer Certificate of Origin (DCO).

[passaro]

LGTM!