A GPU Host Memory Total Can Count the Same Child Twice

Identify the account behind the host-memory offer

Two errors can distort a GPU-host proposal: adding a parent account to its included children, and presenting reclaim events as failed application work. Neither error is repaired by supplying a larger installed-RAM figure.

Linux cgroup v2's memory.current reports current usage for a non-root cgroup and its descendants, in bytes. The controller covers anonymous memory, page cache and several kernel-memory categories. It is a charge account, not simply the sum of application tensor sizes.

Keep this host-side accounting question separate from GPU HBM or VRAM capacity. The cited definitions do not establish a universal mapping of accelerator memory into host charges. The buyer needs an explanation of the actual application's account and hierarchy, rather than a combined host-and-device memory number.

References: [K1]

HM-253: 5 GiB plus 3 GiB is already inside 8 GiB

Fictional example HM-253 stipulates simultaneous, idealized observations in one stable hierarchy. All named cgroups are non-root. Child A has 5 GiB of current charges and child B has 3 GiB. Their parent P reports 8 GiB, including exactly those two children and no other charges. These are invented report fields, not a host measurement. All example amounts use GiB; the actual interfaces use bytes.

The complete stipulated amount is 5 GiB + 3 GiB = 8 GiB. The parent's 8 GiB is another view of that same amount. Adding 8 GiB + 5 GiB + 3 GiB = 16 GiB counts both children's charges twice. It creates no additional memory demand.

A report may show P to describe the whole package and A and B to explain its composition. That is useful detail if the overlap stays visible. For this example, compare the parent total or the complete child breakdown with the requirement. Do not present their sum as a third, larger requirement. The exact equality is stipulated here; an unexplained difference in a real report needs reconciliation.

References: [K1]

The gap below a limit is not memory available to allocate

Stipulate that P's high boundary is 7 GiB and its max boundary is 10 GiB, with no tighter ancestor boundary affecting this arithmetic. At the stated instant, P is 8 GiB - 7 GiB = 1 GiB above high and 10 GiB - 8 GiB = 2 GiB below max. These invented thresholds are not recommendations.

memory.high applies reclaim pressure and throttling; exceeding it alone does not invoke the OOM killer. memory.max is the hard limit: reaching it when usage cannot be reduced invokes the cgroup OOM killer. Temporary overage is documented. Some allocation paths do not invoke that killer and can instead retry, return an allocation error or be ignored, as with readahead.

The 2 GiB difference describes P's position relative to one stated boundary. It establishes neither free physical RAM nor success for a next allocation. The 8 GiB current gauge is neither a peak nor a reservation. No duration or workload timing is supplied, so this snapshot cannot quantify performance or establish how long P was above high.

References: [K1]

Read the named event before assigning an application outcome

The high field counts throttling and direct-reclaim occurrences caused by exceeding high. The max field counts occasions when usage was about to exceed max; unsuccessful reclaim leads to OOM. The oom field records reaching the limit with allocation about to fail, with documented allocation-path exceptions. oom_kill counts processes killed by any OOM killer. These are different observations.

Under the standard default, memory.events includes descendant events. memory.events.local reports only local events. The memory_localevents mount option makes memory.events local too. Preserve the kernel, controller and mount scope alongside a supplied report.

A buyer should therefore reject a summary that silently renames high events as failed inference requests. Even an unchanged oom or oom_kill counter cannot certify that every possible allocation or application failure was absent.

References: [K2]

A separate hierarchy Q shows three events in two places

Now use a separate fictional hierarchy with non-root parent Q, unrelated to P's snapshot. Stipulate unchanged cgroup identities, observations t0 and t1, no counter resets, and standard hierarchical memory.events without memory_localevents. Q has no local high events; child C is the sole source of changing high counts in its subtree.

Q's hierarchical high count goes from 40 at t0 to 43 at t1, a delta of 3. Q's local high count stays at 0. C's local high count goes from 12 to 15, also a delta of 3. Under the stipulated scope, the parent's delta contains the same three events recorded locally at C.

Adding those deltas as 3 + 3 = 6 double-counts the occurrences. The parent's starting count of 40 and C's starting count of 12 do not describe their common interval; the matched changes do. Q's historical count need not equal C's historical count for these three new occurrences to propagate.

The example supplies neither an observation duration nor application-outcome evidence. The count of three consequently supplies no event rate, no count of failed model requests and no count of killed processes. It also supplies no values for max, oom or oom_kill. None can be inferred from the high delta.

References: [K2]

Ask for a reconciled account under the intended workload

Return a proposal to its responsible platform or application provider with the missing scope questions. Which cgroup contains the application, which descendants are included, and which ancestors constrain it? Which values describe one instant, which describe peaks, and which are counter changes over a stated interval? Ask for the exact kernel and cgroup v2 memory-controller context, metric names, units and event-reporting scope.

For a counter comparison, preserve the cgroup identities and explain any discontinuity between observations. For a current-memory comparison, identify the workload stage and concurrent activity represented. A quieter stage in one offer and active execution in another do not establish comparable budgets merely because both reports use GiB.

HM-253 supports an 8 GiB current total under its assumptions. Q supports three high occurrences during its unnamed interval. A useful supplier response retains those conclusions, supplies the missing operating context and addresses the application's actual acceptance requirement. It does not choose a limit by subtracting two fields or promise useful GPU work from a host-memory account.

The related NUMA article addresses where host pages are local to CPU execution. The PyTorch article addresses device allocator storage; the page-cache article addresses the origin of read data. Those remain separate reporting questions. CPU scheduling requests and limits likewise require their own evidence.

Carry selected equipment into a physical deployment inquiry

Formal application operation, Linux configuration, memory tuning and diagnosis remain with the appointed platform and application providers. This article interprets reporting evidence and provides no field procedure or work approval.

If the selected equipment also needs receiving, rack integration, onsite installation or IT cabling, Leviathan's Complete Physical Deployment service and project inquiry below are relevant to that physical package. Share a nonconfidential equipment summary, site, required physical stages and receiving team. The engagement defines the included work, resources and handoff records.

References: [L1]