ContactCV

Projects

Active2026

A memory-pressure guard for GB10 Docker workloads

A Linux guard built after large model loads left my GX10 unresponsive. It estimates memory headroom and stops selected Docker workloads when pressure or allocation rate crosses configured limits.

Read the write-up
Current soft threshold
8 GiB
Current hard threshold
3 GiB

Implemented for Docker workloads. Current thresholds still need the earlier stress-test sequence.

Tools and project details
Status
Implemented for Docker workloads. Current thresholds still need the earlier stress-test sequence.
Stack
  • Python
  • Linux
  • systemd
  • cgroup v2
  • Docker
  • NVIDIA GB10
Role
Failure analysis, guard implementation, and documentation
Covered runtime
Docker scopes

Case study

The intervention

The guard reads Linux memory counters and pressure signals, tracks rapid allocation ramps, and stops selected cgroup v2 workloads. I added host-service protections and telemetry to help diagnose the failure and recovery sequence.

What remains untested

The documented stress observations used a 4 GiB hard floor and 1 GiB kernel reserve. Current defaults use 3 GiB and 256 MiB; the same stress sequence has not been repeated with them, and raw traces are not public.

The scan covers selected Docker workloads. Native processes, rootless Docker, and MicroK8s/containerd pods are outside its scope. The headroom calculation is a heuristic, and startup cache dropping also occurs in dry-run mode.