--- title: "Two AI Worker RSS Totals Can Count the Same Resident Pages Twice" description: "Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21." canonical: "https://www.leviathansystems.co/articles/ai-worker-rss-pss-shared-resident-pages" last-updated: "2026-10-21" --- # Two AI Worker RSS Totals Can Count the Same Resident Pages Twice Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21. Adding worker RSS can count the same physical pages more than once. PSS apportions shared pages, but a sum covering only selected workers can leave shares outside the report. Before treating either sum as a fleet RAM requirement, establish which resident backing is shared, who maps it and what the account includes. A lower pair PSS can reflect another sharer without reducing the workers' data or the defined physical backing. ## 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](https://man7.org/linux/man-pages/man5/proc_pid_smaps.5.html), [K1](https://docs.kernel.org/6.6/filesystems/proc.html) ## 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](https://docs.kernel.org/6.6/filesystems/proc.html), [K2](https://raw.githubusercontent.com/torvalds/linux/v6.6/fs/proc/task_mmu.c) ## 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](https://docs.kernel.org/6.6/filesystems/proc.html) ## 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](https://docs.kernel.org/6.6/filesystems/proc.html) ## 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](https://www.leviathansystems.co/services/gpu-assembly) ## Primary sources - [K1 — Linux 6.6: The /proc Filesystem, resident and proportional mapping accounts](https://docs.kernel.org/6.6/filesystems/proc.html). Checked 2026-10-20. Version-pinned definitions of RSS/PSS, present page sharing, private copies and mapping-report races. Explicitly excludes hugetlbfs pages from the documented RSS/PSS fields. - [K2 — Linux v6.6: Proportional set size accounting implementation](https://raw.githubusercontent.com/torvalds/linux/v6.6/fs/proc/task_mmu.c). Checked 2026-10-20. The PSS accounting comments and implementation show division by page mapping count and finite-precision accumulation. Supports idealized proportional arithmetic without promising exact printed totals. - [M1 — Linux man-pages 6.19: proc_pid_smaps(5)](https://man7.org/linux/man-pages/man5/proc_pid_smaps.5.html). Checked 2026-10-20. Manual page dated February 8, 2026; distinguishes mapping size, resident RAM, proportional share and swapped data. - [L1 — Leviathan Systems: Rack Assembly & Preparation](https://www.leviathansystems.co/services/gpu-assembly). Checked 2026-10-20. Describes receiving, equipment preparation, rack assembly and agreed physical handoff inputs. The service connection here concerns separately selected equipment. ## Related Leviathan resources - [Model mapping, resident payload and loading readiness](/articles/model-memory-mapped-load-deferred-cpu-pages) - [Cgroup host-memory charges, hierarchy and event scope](/articles/gpu-host-cgroup-memory-charge-limit-event-scope) - [Rack Assembly & Preparation for selected equipment](/services/gpu-assembly) - [Discuss a separate physical preparation project](/contact?service=gpu-assembly&from=%2Farticles%2Fai-worker-rss-pss-shared-resident-pages) - [SQL NULL in AI Datasets: Which Rows and Values Count?](/articles/ai-dataset-sql-null-predicate-aggregate-population) ## Does the selected equipment need receiving or rack preparation? Share the approved equipment configuration, rack arrangement, proposed location and required handoff to discuss the physical preparation package. [Discuss the scope](/contact?service=gpu-assembly&from=/articles/ai-worker-rss-pss-shared-resident-pages)