Two AI Worker RSS Totals Can Count the Same Resident Pages Twice

RSS counts resident mappings; PSS apportions shared pages

A worker has a virtual address space through which it accesses data. Different processes can map the same physical pages. The Linux man-pages description of smaps distinguishes mapping size, the portion resident in RAM reported as Rss, and the proportional share reported as Pss. A virtual extent and its resident portion therefore answer different questions.

Linux 6.6 defines PSS by dividing each resident page among the processes sharing it. With one mapping per participating process, a private page contributes its full size to that process; a page shared by two contributes half to each. Its full resident size still appears in each participant's RSS.

PSS changes the attribution of shared resident memory. It does not restrict a worker to accessing only its attributed fraction. Nor does adding RSS automatically identify how many distinct physical pages back the workers.

References: [M1][K1]

PM-46 defines the data before adding the worker totals

PM-46 is an invented accounting example, not a host measurement or an AI benchmark. Worker A has 4 MiB of resident private data and worker B has a different 4 MiB. Both map the same 12 MiB of shared resident data. Those three physical regions have no overlap except that A and B both map the shared region.

Assume ordinary 4 KiB pages, each relevant page mapped once per participating process, stable identities and simultaneous observations at each state. There is no swap, hugetlbfs backing or other huge-page backing. The account excludes page tables, other kernel memory, device memory and all unrelated mappings. Linux 6.6 explicitly excludes hugetlbfs-backed pages from its Rss and Pss fields. The values below are these data regions' contributions to RSS and PSS, rather than complete process totals.

All amounts use binary units: 1 MiB is 1,048,576 bytes and 4 KiB is 4,096 bytes. The equations use ideal proportional attribution. Linux 6.6 uses finite-precision PSS accumulation, so these equations do not predict byte-exact printed counter values.

References: [K1][K2]

Two RSS contributions add to 32 MiB for 20 MiB of backing

For the defined data, A's RSS contribution is 4 MiB + 12 MiB = 16 MiB. B's contribution is also 16 MiB. Their sum is 32 MiB.

The distinct physical data is A's private 4 MiB, B's private 4 MiB and one shared 12 MiB region: 4 MiB + 4 MiB + 12 MiB = 20 MiB. The RSS sum repeats that 12 MiB region. The extra 12 MiB in the sum is an accounting overlap, rather than additional backing required by this state.

Only A and B share the 12 MiB region in this first state. Each receives an ideal PSS contribution of 4 MiB + 12 MiB / 2 = 10 MiB. The complete pair's 10 MiB + 10 MiB = 20 MiB then matches the defined unique data.

This reconciliation works because the example identifies every relevant region and every participant. RSS alone would not distinguish this arrangement from two workers whose resident data occupies entirely separate physical pages.

A third sharer lowers the pair's PSS without removing data

Now introduce process C, which maps every page of the already resident shared 12 MiB region once. C has no private data within this defined account; its other process resources remain outside the example. No defined data is allocated, copied, removed or evicted between the two states. A and B retain their original mappings and private data.

Each shared page now has three participants. A's ideal PSS contribution becomes 4 MiB + 12 MiB / 3 = 8 MiB, and B's becomes 8 MiB. Their selected pair therefore reports 16 MiB of ideal PSS instead of 20 MiB. Each original worker's RSS contribution remains 16 MiB.

C receives the remaining 12 MiB / 3 = 4 MiB share. Including all three gives 8 MiB + 8 MiB + 4 MiB = 20 MiB. The distinct physical data is still the same 20 MiB. The original pair's missing 4 MiB has moved into another participant's attribution.

The pair's PSS has fallen by 20%, yet none of its defined resident data has disappeared. If C later ceases to map those pages while A and B retain them, the pair's ideal PSS returns to 20 MiB without requiring new backing for those data.

Shared backing needs an explanation beyond a model or file label

For an actual proposal, the important identity is the physical backing represented by the report. Two workers referring to the same model revision do not, by that statement alone, establish that their resident pages are the same physical pages. Conversely, two process entries do not establish two physical copies.

Linux 6.6 notes that a page in a shared mapping is accounted as private when only one process currently maps it. It also describes a modified private file mapping replacing a file page with a private anonymous copy. A mapping's permitted sharing and its present page sharing are therefore separate facts.

The supplier's explanation should identify which resident regions remain common, which are distinct copies and whether that relationship changes during the proposed work. Subtracting an assumed model size from summed RSS would skip that essential evidence.

References: [K1]

Compare two proposals with the sharing population visible

Consider two conceptual proposals reporting the same worker pair, A and B, for the same defined data and workload state. Proposal One uses PM-46's first state: only A and B map the shared region. Proposal Two uses its second state: C also maps that region, while the headline report still selects only A and B.

Both report 16 MiB of RSS contribution for each original worker. One reports a pair PSS of 20 MiB; Two reports an ideal pair PSS of 16 MiB. Ranking Two as requiring 20% less resident data would be unsupported. Its complete sharing population still accounts for 20 MiB.

A useful comparison names the selected workers and the additional participants affecting their attribution. It also says whether those additional participants belong to the offered operating arrangement. Reporting only the two named workers cannot make an outside share vanish from the physical account.

These proposals establish an accounting difference. They supply no measured throughput, latency, peak memory or workload acceptance result.

Resolve backing, population and time before accepting a RAM requirement

Before accepting a worker-memory sum as a capacity requirement, ask its responsible platform or application owner to reconcile the resident data it represents. The explanation needs the metric and units, included mappings, genuinely shared backing, complete sharing population and the workload state represented. Preserve process identity and timing across a comparison; separate observations can describe different populations and data.

The Linux 6.6 documentation warns that mapping reports can race with mapping changes. A set of supplied process observations should not silently be treated as one atomic fleet snapshot. PM-46 stipulates simultaneous stable states precisely to remove that uncertainty from its arithmetic.

An apportioned current total also leaves future demand unresolved. In PM-46, C's presence makes the selected pair's share smaller without making the pair's data smaller. Actual loading, execution and concurrency may involve other regions and later peaks. The responsible owner's capacity case must address the intended work and its complete memory boundary; the example supplies neither a memory-limit setting nor evidence that a GPU workload fits.

The related model-loading article explains mapping versus residency and readiness stages. The cgroup article explains hierarchical charges and events. Neither boundary can be substituted for this process-page attribution account, and overlapping views should not simply be added.

References: [K1]

Carry selected equipment into its physical preparation scope

Once the responsible owners have selected the hardware, it may also need receiving, preparation or rack assembly. Leviathan's Rack Assembly & Preparation service and project inquiry below address that physical package.

Share a nonconfidential equipment summary, approved configuration, rack arrangement, proposed location and required handoff. Application memory assessment and software acceptance remain with the appointed platform and application owners; the physical preparation inquiry defines its own included tasks and deliverables.

References: [L1]