The direct answer
Give a preprocessing job a reviewed memory-controller scope and distinguish pressure, allocation failure, OOM activity and application completion. Neither a configured limit nor a changed counter proves that every worker stopped or that its output is complete, authorized and safe to release.
Choose the resource decision before choosing numbers
A fictional AI intake service preprocesses one already admitted note. A worker becomes slow, and an operator sees a memory-related counter. Immediately labelling the job “killed safely” could hide either continuing work or an incomplete artifact.
The upload guide requires separate processing bounds. The map worksheet explains why concurrency and submission buffering do not establish a physical-memory ceiling. This guide adds a kernel-controller interpretation boundary, not another parser or worker-launch recipe.
Select trusted fixed worker W-A, job J-A and exclusively owned cgroup subtree C-A. Propose symbolic high boundary H-A below maximum M-A and an explicit group-OOM policy. No numerical values are recommended. The actual controller, ancestor policies, membership and accounting association are unknown here. Every card below is PROPOSED_UNRUN.
Keep pressure, maximum enforcement and accounting separate
The official cgroup-v2 reference defines memory.current for a group and descendants. Charged use includes anonymous/page-cache, kernel and socket memory, without complete coverage; ancestor restrictions also apply.
memory.high throttles and reclaims without itself invoking OOM, and can be breached. memory.max invokes cgroup OOM when reached usage cannot be reduced, though temporary overage and non-OOM allocation failures are possible. Memory interface definitions.
Therefore the proposed H-A policy asks an operator to classify pressure rather than declare completion. M-A supplies a different failure boundary, not evidence of an instantaneous RSS, allocation or whole-machine ceiling. Keep monitoring and response ownership explicit; this article implements neither. An actual deployment must reconcile the complete effective hierarchy and its supported memory-accounting scope before admitting the resource plan.
The selected reference is unversioned. Its October 2015 header is not a current kernel-release or installed-host observation. No live controller support or effective setting was inspected, and no alternate container or operating-system profile is substituted.
Do not promote group OOM into universal job termination
memory.oom.group treats the group and descendants as one OOM-kill unit, except protected tasks with oom_score_adj of -1000. Cgroup OOM does not kill outside its group. Group-OOM scope and exception.
For J-A, establish the complete intended process membership and keep the group association stable for its lifetime. Do not reuse a convenient group name as proof that all helpers belong to this attempt. Unknown migration, escaped work, unrelated residents or protected members prevents a complete-job interpretation.
Keep the resource disposition separate from the application outcome. A partially produced note is not valid merely because a resource failure occurred. Nor does an OOM signal attest that a prior external operation was rolled back. This selected worker must independently have no model, network or business effects; that prerequisite is unimplemented here. Any output stays quarantined until its ordinary completeness, content and current-rights checks pass.
Bind counter evidence to a job without inventing event identity
memory.events is hierarchical unless memory_localevents changes it; memory.events.local is local. oom records limit-reached impending failures, omitting cases without OOM-killer consideration; oom_kill counts member processes killed by any OOM killer; oom_group_kill counts group occurrences. Memory event definitions.
The review sheet must identify the effective option profile and exact signal source, not merely a column called OOM. A future observation also needs a supported baseline and interval associated with exclusively owned J-A/C-A. An old total, a descendant event or a group reused across jobs cannot identify this attempt by itself.
Even a correctly associated change answers only the selected counter question. Retain separate fields for pressure evidence, allocation/failure evidence, process-lifecycle coverage, output validation and release disposition. Use minimized job/group/profile references; no raw note contents or detailed host inventory is needed to explain a hold.
Walk eight inert memory-condition cards
| Card | Proposed condition | Disposition |
|---|---|---|
| 1. Ordinary note | Complete supported W-A/J-A/C-A profile and all independent prerequisites established. | Conditionally admit the intended local resource plan; output release remains separate. |
| 2. Pressure as a ceiling | H-A alone is presented as proof of a strict byte bound. | Reject that evidence claim; classify the documented pressure condition. |
| 3. Maximum as an instantaneous peak | M-A is presented as an RSS or complete-host guarantee. | Reject; preserve accounting, overage and failure limits. |
| 4. Group coverage unknown | Group policy is selected but exceptions or complete membership are unresolved. | No claim that every job process stopped. |
| 5. Hierarchical signal | A counter changes, but local versus descendant scope is unestablished. | Hold attribution; reconcile the signal and effective option profile. |
| 6. Old or reused baseline | A historical total lacks a supported J-A interval and ownership association. | Do not classify this attempt as failed or successful. |
| 7. Partial result | Memory failure is reported while output or earlier effects remain unresolved. | Hold release; no rollback, erasure or automatic replay inference. |
| 8. Coverage drift | Work escapes C-A, profile changes or another resource/current-rights gate fails. | Outside coverage or independently denied; memory policy supplies no override. |
Keep the useful positive smaller than a containment guarantee
The ordinary positive remains one small authorized note processed by a trusted fixed local worker. It is only conditionally eligible after actual controller enablement, ancestor policy, dedicated stable membership without escape, charged-memory association, job baseline, current rights and output validation are independently supported. These are release requirements, not observations established by this documentation review.
CPU time, wall time, disk, network, identity and model spend remain separate boundaries. This worksheet supplies no cgroup manager, tuning commands, monitor, recovery loop or worker sandbox. It does not prove the host survives every resource failure.
No candidate cgroupfs, sysfs, procfs, kernel or runtime host state was inspected or changed. No controller, process, allocation, pressure, OOM or runtime fixture was exercised; no model or API experiment occurred. Boundary remains prelaunch with planned request-path checks, not shipped kernel-resource enforcement.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.