---
title: "How CPU Cache Allocation Masks Relate to Occupancy and Sharing"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/cpu-cache-allocation-masks-versus-occupancy-sharing"
last-updated: "2026-10-20"
---

# How CPU Cache Allocation Masks Relate to Occupancy and Sharing

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

A CPU cache allocation mask describes where a group may make new cache allocations within a named cache domain. It does not report the bytes currently attributed to that group or establish exclusive ownership. Two groups can each have a half-size shareable mask and still overlap. For CPU work feeding a GPU, assess allocation eligibility, measured occupancy and sharing separately; a smaller eligible region also does not immediately remove previously cached lines.

## Identify what the promised cache share actually controls

A GPU-host proposal might give a CPU-side preprocessing stage 50% of the last-level cache and call that share dedicated. Before using the claim to compare offers, establish whether it describes an allocation policy, observed cache use or exclusion of other allocation groups. Those are three different promises.

Intel's February 11, 2016 CAT introduction describes a class of service, or CLOS, with an associated capacity bitmask. Cache Allocation Technology controls the cache space into which that class can allocate. Allocation here concerns filling the controlled CPU cache, rather than obtaining application RAM or reserving GPU HBM.

Intel distinguishes Cache Monitoring Technology from CAT. Linux 6.6 likewise documents monitoring and control as independent capabilities: a system can support either or both. An occupancy report therefore does not itself establish that cache allocation control is available.

The interface behavior discussed here is scoped to the Linux 6.6 x86 resctrl documentation. The offered processor, firmware, kernel and enabled features still need identification. This is an explanation for evaluating a resource claim; implementation and workload validation belong to the appointed platform and application owners.

References: [I16](https://www.intel.com/content/www/us/en/developer/articles/technical/introduction-to-cache-allocation-technology.html), [IR](https://www.intel.com/content/www/us/en/architecture-and-technology/resource-director-technology.html), [K66](https://docs.kernel.org/6.6/arch/x86/resctrl.html)

## Attach the percentage to a cache level and domain

A cache share needs a denominator. Identify the cache level, the cache instance and the CPU resources sharing it before comparing percentages. Linux 6.6 uses Cache IDs because a socket or core need not correspond to exactly one shared-cache boundary.

If two groups' masks apply to different cache instances, matching position labels do not establish overlap in one physical cache. Conversely, different CPU assignments do not establish separate cache instances. The relevant comparison pairs each mask with its domain.

Keep that identity attached to occupancy observations too. A whole-server cache-capacity figure cannot supply a missing domain denominator. A proposal stating 50% on one instance and another stating 50% across an unspecified collection leave different questions unresolved, even if both hosts have the same advertised total cache.

References: [K66](https://docs.kernel.org/6.6/arch/x86/resctrl.html)

## CA-335: two half-size masks overlap in two positions

CA-335 is an invented allocation comparison within one cache domain. Stipulate eight equal symbolic allocation positions numbered 0 through 7 and two groups in shareable mode. A is eligible to allocate in positions 0, 1, 2 and 3. B is eligible in positions 2, 3, 4 and 5. These are symbolic permissions, not a configuration recipe or a specification for an eight-way processor.

Each permitted set contains four of eight positions: 4 / 8 = 50%. Their intersection is positions 2 and 3, containing two positions. Their union is positions 0 through 5, containing six.

Adding 50% + 50% = 100% counts permission for the two overlapping positions twice. The distinct positions covered by at least one group amount to 6 / 8 = 75% of this example's grid. The masks therefore do not divide the cache into two disjoint halves.

Positions 0 and 1 appear only in A's mask among these two groups, and positions 4 and 5 only in B's. That comparison says nothing about other groups. Likewise, positions 6 and 7 being absent from A and B does not establish that they are unused by the system.

None of this arithmetic counts resident cache lines or occupied bytes. It describes which positions are eligible for allocation. No occupancy observations, cache capacity in bytes, application accesses or timing results have been supplied. An observed use figure cannot be calculated from the two masks.

References: [I16](https://www.intel.com/content/www/us/en/developer/articles/technical/introduction-to-cache-allocation-technology.html), [K66](https://docs.kernel.org/6.6/arch/x86/resctrl.html)

## Nonoverlap is a separate allocation condition

Linux 6.6 documents shareable mode as permitting overlapping allocations. Its exclusive-mode example requires an allocation without overlap with other resource groups, including the default group. An existing exclusive allocation is also protected against a conflicting group allocation.

CA-335's A and B cannot support that exclusivity claim while their two-position intersection remains. Merely calling each mask half-size leaves the intersection unchanged. In a separate symbolic comparison, A's 0 through 3 and B's 4 through 7 would be disjoint. That establishes a relationship between those two permitted sets; confirming an exclusive arrangement still requires the complete allocation context.

The useful meaning of exclusive here concerns allocation overlap. It does not certify private ownership of every line an application can access. The same kernel reference notes hardware-shareable resources and platform device controls. A buyer should therefore identify the exact exclusion being promised rather than extend a group-allocation statement into a security boundary or a strict response-time guarantee.

References: [K66](https://docs.kernel.org/6.6/arch/x86/resctrl.html)

## Occupancy describes an attributed state at an observation

Intel's December 2025 RDT Architecture Specification, revision 1.3, distinguishes per-RMID occupancy monitoring from per-CLOS allocation control. An RMID is a resource monitoring identifier. Linux 6.6 describes llc_occupancy as a current snapshot for the corresponding monitoring or control-and-monitoring group, organized by L3 domain.

For CA-335, supplying A's four-position mask establishes its permitted set. Supplying a separate occupancy observation would add a state measurement at a particular time. The second fact neither follows numerically from the first nor replaces it.

The word attributed matters when deciding what an observation proves. An account of cached data is not an inventory of addresses that only that group can read. It also supplies no hit rate, miss cost, completed-request count or response-time distribution. Those are different observations.

Suppose two suppliers offer the same eligible fraction but show different occupancy values. The difference alone does not select the better offer. It leaves open whether the application stages, concurrent activity, group scope and observation times are comparable. Equally, matching occupancy values would leave the sharing arrangements unresolved.

References: [I25](https://cdrdv2-public.intel.com/851356/356688-004-intel-rdt-architecture-spec.pdf), [K66](https://docs.kernel.org/6.6/arch/x86/resctrl.html)

## A smaller allocation region does not immediately empty the old one

Linux 6.6 states that moving a task between groups changes new allocations. Existing hits do not update occupancy attribution. Moving the task to a smaller cache partition does not evict its previously cached lines, which it may continue using.

A cache hit uses a line already present; a later fill needs an eligible position for a new allocation. For a mask reduction, distinguish that later fill from a hit: the revised mask describes where later allocations are eligible, while previously cached data can remain accessible on a hit outside the current allocation area. The smaller mask is not evidence that those lines were flushed. That conclusion follows from the documented allocation and hit behavior.

Consider a fictional CPU request handler whose group assignment changes between observations. Immediately afterward, the old group's occupancy remains nonzero and the new group's report is low. That pattern does not, by itself, prove that the task is still executing under its old assignment. Retained lines and their earlier attribution are a documented explanation that must be considered.

As lines are evicted and reused, later fills can change the reported distribution. The supplied masks do not establish how long that takes. A comparison made just after reassignment and one made during a later workload stage consequently answer different timing questions. Ask which state transition preceded each result before treating either observation as representative of the offered steady workload.

References: [K66](https://docs.kernel.org/6.6/arch/x86/resctrl.html)

## Evaluate the proposal against the promise it actually makes

Return to the CPU stage feeding a GPU. If the requirement is eligibility for half of one named cache domain, CA-335's A meets that stipulated fraction. If the requirement is a disjoint half relative to B, the same example fails because positions 2 and 3 overlap. If the requirement is a certain observed occupancy or response time, CA-335 leaves it unanswered.

Ask the responsible supplier to connect the exact host and enabled capabilities to the relevant cache domain, the workload's effective allocation, other allocations and the claimed sharing mode. For an occupancy result, retain the group identity, metric, units, time and preceding assignment history. A policy description and a state observation can both be correct while referring to different parts of that account.

For a performance promise, request representative application results under the intended concurrent load and stated acceptance target. The comparison should identify the CPU stage and its useful output within the GPU workflow. Neither a larger mask nor a larger occupancy value establishes that more requests finish on time.

The related false-sharing article addresses independent values contending within one coherent line. The NUMA article addresses CPU execution and host-page locality. The cgroup article addresses host-memory charges and limits. Those remain useful adjacent comparisons, while this decision turns on permitted cache fills, overlap and time-dependent attribution.

## Connect selected hardware to a physical installation scope

If the cache and workload assessment leads to selected equipment that needs onsite installation, Leviathan's rack-and-stack service and project inquiry below provide the relevant physical next step.

Share the equipment list, site, released rack positions, IT connection requirements and required handoff records to discuss scope and availability. The published service covers agreed equipment mounting, IT cabling, labeling and physical checks. Standard rack installation does not include operating-system configuration or software commissioning.

References: [L1](https://www.leviathansystems.co/services/rack-and-stack)

## Primary sources

- [K66 — Linux 6.6: User Interface for Resource Control feature](https://docs.kernel.org/6.6/arch/x86/resctrl.html). Checked 2026-10-20. Version-pinned x86 interface: sections 24.2–24.3 cover capabilities, Cache IDs and allocation/attribution transitions; 24.5 covers retained hits, 24.5.2.3 covers sharing modes, and 24.6.1 defines current LLC snapshots. These definitions do not establish support or workload results for an offered host.
- [I16 — Intel: Introduction to Cache Allocation Technology in the Intel Xeon Processor E5 v4 Family, February 11, 2016](https://www.intel.com/content/www/us/en/developer/articles/technical/introduction-to-cache-allocation-technology.html). Checked 2026-10-20. Historical CLOS and capacity-bitmask explanation supports allocation size and overlap. Generation-specific availability statements are not generalized to current servers.
- [IR — Intel Resource Director Technology framework: CMT and CAT](https://www.intel.com/content/www/us/en/architecture-and-technology/resource-director-technology.html). Checked 2026-10-20. Unversioned framework overview distinguishes cache monitoring from cache allocation. Marketing benefits are not adopted as workload guarantees.
- [I25 — Intel RDT Architecture Specification, 356688-004US, revision 1.3, December 2025](https://cdrdv2-public.intel.com/851356/356688-004-intel-rdt-architecture-spec.pdf). Checked 2026-10-20. Sections 3.1.3 and 3.2.3, printed pages 26 and 29, corroborate per-RMID occupancy and per-CLOS cache-fill control. The specification warns against finalizing designs from its development information; no platform selection is based on it.
- [L1 — Leviathan Systems: Rack-and-stack installation](https://www.leviathansystems.co/services/rack-and-stack). Checked 2026-10-20. Published mounting, IT cabling, labels and physical-check scope; OS configuration and software commissioning are not standard rack-installation inclusions.

## Related Leviathan resources

- [Understand false sharing between independent CPU values](/articles/cpu-false-sharing-cache-line-independent-data)
- [Compare NUMA-local host memory with total RAM](/articles/gpu-server-numa-local-memory-versus-total-ram)
- [Interpret cgroup host-memory charges, limits and events](/articles/gpu-host-cgroup-memory-charge-limit-event-scope)
- [Rack-and-stack physical installation](/services/rack-and-stack)
- [Discuss installation of selected equipment](/contact?service=rack-and-stack&from=%2Farticles%2Fcpu-cache-allocation-masks-versus-occupancy-sharing)

## Does the selected equipment need physical installation?

Share the equipment, site, released rack positions, IT connections and physical handoff needs to discuss installation scope and availability.

[Discuss the scope](/contact?service=rack-and-stack&from=/articles/cpu-cache-allocation-masks-versus-occupancy-sharing)