Skip to content

Uniform Memory Access

A shared-memory processor domain with no local-versus-remote main-memory placement tier.

Version
v1 · 2026-10-17 · History
Domain-specific #
14347
Domain group
Applied Sciences & Engineering
Origin domain
Computer Science & Software Engineering
Subdomain
Computer Architecture → Computer Science & Software Engineering
Aliases
UMA

Core Idea

Uniform memory access (UMA) describes a shared-memory multiprocessor domain in which the location of an address in main memory does not create a privileged near class for some processors and a far class for others. The claim needs a declared group of processors, an addressable main-memory domain and a specified hardware mode. It concerns the architectural processor-to-memory placement relation, not a promise that every load, cache hit or program run takes exactly the same time.[1][2][3]

Two designs make the distinction concrete. Intel describes a Xeon Scalable Processor Max Series UMA domain mode with one contiguous address space interleaved among memory controllers and equal core access to the last-level cache and memory within that mode. Sun's Starfire engineers instead routed even a same-board main-memory access across a global interconnect; they described memory access time as independent of which system board held the memory. These are unlike mechanisms that instantiate a location-uniform main-memory class inside their respective domains.[1][2][3]

Structural Signature

  • Declared multiprocessor domain. Identify the processors and configuration being compared. Intel's mode is a configured domain; Starfire can divide its boards into protected system domains. A claim about one domain does not automatically extend across the entire machine.[1][2]
  • Shared addressable main memory. The processors in the domain must be able to request memory locations in the relevant shared address space. Separate private memories without this relation are a different carrier.
  • Request-routing organization. There must be a route from a processor's main-memory request to the location that holds the addressed data. Controller interleaving and a multi-board global path are two source-attested implementations; neither particular mechanism defines UMA by itself.[1][3]
  • No placement-based near/far main-memory tier. The defining test asks whether changing the requester or the location of the addressed main memory introduces an architectural local-versus-remote access class within the declared domain. A same-board shortcut with materially different latency and bandwidth fails this test.[1][3][4]
  • Operational qualification. Cache state, queueing, contention and workload behavior can change observed response times. The absence of a memory-placement tier is the identity being claimed; identical timing for every transaction is not.[3][4]

What It Is Not

  • Not merely a shared address space. Shared addressing says that processors can name common memory, not that access lacks a locality tier. The Sun Fire E25K manual describes a shared-memory interconnect with different same-board and off-board latency and bandwidth classes.[4]
  • Not merely a crossbar. Both Starfire and E25K have global interconnect machinery, but E25K's same-board paths can avoid Sun Fireplane traffic. Path behavior, not the word crossbar, decides the classification.[2][3][4]
  • Not exact observed latency for every operation. Cache hits, cache misses, contention and service queues remain different events. A board-independent main-memory placement class does not make them equal.[3]
  • Not automatically a CPU–GPU property. A heterogeneous system's shared or coherent address space does not alone show that its processors have the same main-memory placement class.
  • Not one address space across protected Starfire domains. Each configured system domain is a separate shared-memory SMP system. The within-domain claim should not be silently extended across isolated domains.[2]

Scope of Application

UMA is a computer-architecture classification for a declared shared-memory processor domain and its main-memory access organization. Intel's manufacturer account supplies a package-level UMA mode, while the Starfire accounts supply a multi-board server design. In each case the analyst must state the mode or domain before interpreting uniform.[1][2][3]

The contrast is with a location-tier design, such as Intel's sub-NUMA clustering mode or E25K's board-local advantage. The sources support this architectural comparison. They do not show that UMA always improves application performance, that every bus or crossbar system is uniform, or that placement can never matter to caches and other resources.[1][4]

Clarity

Keep four questions separate. Can processors name shared memory? Which domain and mode are configured? Does main-memory placement create a local/remote class? What latency did a particular operation actually experience? Only the third question, within the scope fixed by the first two, identifies UMA. The fourth is a measurement with additional causes.[1][3][4]

Intel says its UMA domain interleaves addresses among controllers and gives all cores equal access to last-level cache and memory, whereas its sub-NUMA clusters expose locality to software. Starfire's global route is a different physical arrangement. Neither account licenses an unqualified claim that all cache hits, loaded links or contended requests take one fixed number of nanoseconds.[1][3]

Manages Complexity

A large machine can have processors, cache slices, controllers, boards, routers and several memory technologies. The UMA test reduces a first architectural description to domain → shared main-memory locations → request path → placement classes. This prevents a reader from mistaking a single address space or an impressive crossbar for an absence of near/far main-memory tiers.[1][4]

The reduction has a limit. It classifies one access relation; it does not replace workload analysis. Intel explicitly describes modes with different locality exposure, and the E25K manual separates interconnect latency classes from other ways of measuring memory access. These details still matter after the architectural class is named.[1][4]

Abstract Reasoning

First declare the processor set, address space and active hardware mode. Then trace a main-memory request from each relevant requester to memory locations in every placement class, including the seemingly easiest same-board or same-controller destination. Ask whether that destination can take a privileged local path, and separate the resulting location class from cache state and queueing.[1][3][4]

The counterexample is instructive. E25K has an interconnect and shared memory, yet its manual says same-board accesses avoid Sun Fireplane traffic and lists distinct same-board and other-board pin-to-pin latency classes. Thus shared addressing and a global crossbar are insufficient premises for UMA. Conversely, Starfire's engineers state that even same-board memory takes the global route, explaining their board-independent memory-access class.[3][4]

Knowledge Transfer

The role test transfers from an Intel package mode to a Sun multi-board server: identify the domain, shared addresses, routing paths and placement classes. The implementation does not transfer. Controller interleaving in a processor package is not a 16-by-16 centerplane data crossbar, and a Starfire system domain is not Intel's sub-NUMA cluster.[1][2][3]

The distinction also tells a reader what further evidence is needed elsewhere. A new machine advertised as coherent, shared or crossbar connected cannot be classified from those words alone; its local and remote main-memory paths must be checked. This is a diagnostic transfer, not evidence that an uninspected machine is UMA.

Examples

Intel Xeon Scalable Processor Max Series UMA domain mode

Intel describes a selectable UMA domain in which a single contiguous address space is interleaved across the memory controllers. The requesters are the cores in that configured domain; the carrier is its addressable memory; the routing organization distributes addresses among controllers; and Intel says all cores have equal access to the last-level cache and memory in the domain. The same article contrasts sub-NUMA clustering, which maps nearby controller and cache resources into exposed locality domains. This example supports a configured package/domain class, not a claim about every memory mode or every transaction's elapsed time.[1]

Mapped back: declared UMA mode → common address space → controller interleaving → no exposed near/far main-memory class → observed timing remains workload dependent.

Sun Enterprise 10000 Starfire configured system domain

The Starfire interconnect used four address routers and a 16-by-16 centerplane data crossbar for a design supporting up to 64 UltraSPARC processors. Its engineers say that even a request for main memory on the requester's own board traverses the global interconnect, and that memory-access time is independent of the board holding that memory. A protected Starfire system domain is itself a shared-memory SMP system; the uniformity claim is bounded to such a configured domain, not all isolated domains combined.[2][3]

Mapped back: one protected domain → shared board-attached memory → forced global path → no privileged same-board main-memory class → no promise of constant cache or contention timing.

Sun Fire E25K near miss

E25K is not the Starfire design. Its manufacturer manual reports that same-board memory paths avoid Sun Fireplane interconnect traffic and have higher peak bandwidth than off-board paths. Table 4-3 gives calculated pin-to-pin memory latency classes of 180–207 ns for same-board locations and 333 or 440 ns for another board, under the table's stated conditions. This is a shared-memory crossbar machine with a placement tier and therefore a negative case for the entry's UMA identity.[4]

Structural Tensions

  • T1: Uniform global path versus a local shortcut. Starfire's engineers kept even same-board memory on the global route. They say a local shortcut could save some cycles but would complicate the design; E25K illustrates a later architecture with a board-local advantage. The competing values are simpler board-independent paths and potentially faster local access, with a locality distinction. Diagnostic: does a same-board main-memory miss bypass the global route, and what access class results? This is a design comparison, not a claim that one machine is universally faster.[3][4]
  • T2: One UMA domain versus exposed sub-NUMA locality. Intel describes UMA as one interleaved domain with equal access and SNC as domains that expose local controllers and cache slices. The former avoids a declared near-memory tier for software to manage; the latter provides locality information that placement-aware software can use, with corresponding configuration and placement demands. Diagnostic: which mode is active, and what locality does it expose? The source does not imply that either mode wins for every workload.[1]

Structural–Framed Character

The entry is mixed, leaning structural within computer architecture. Processor, memory, address and path roles travel literally between Intel and Sun designs. The locality relation is descriptive, but the chosen hardware mode and protected domain frame where it holds. Performance preference is a separate, workload-dependent judgment.[1][2][3]

Engineers can construct different routes to the same architectural class. Manufacturer mode names and design institutions document configurations, but the processor-to-main-memory path relation can be inspected independently of those labels. Recognition requires declaring the shared-memory domain and testing whether main-memory location creates a privileged tier; a coherent address space or crossbar without that test is insufficient. Its character: a domain-bounded shared-memory architecture class defined by the absence of local-versus-remote main-memory placement tiers, with observed timing left qualified.[1][4]

Structural Core vs. Domain Accent

A highly general skeleton would be access to a resource without a requester-location tier. The domain accent here is indispensable: the requesters are processors, the resource is shared main memory, the tested routes connect cores to memory controllers or boards, and the scope is a configured multiprocessor domain. A generic statement about equal access to other resources is not, by itself, UMA.

Whether location-invariant access has a useful cross-domain Prime identity would need independent examples and catalog review. The two source-supported architectures establish this computer-architecture entry, not such a broader promotion.

This entry is part of Invariance.

Invariance is a strict internal constituent: within the declared mode and shared-memory domain, changing an eligible requester or main-memory placement preserves the absence of an architectural near/far memory tier. This is a preservation of placement class, not a claim that every operation takes identical time. The comparison has a real counterfactual: if an eligible location gains a privileged local path, the system is NUMA-like rather than this UMA class.[1][3][4]

Shared Memory names a broader resource or programming relation in which multiple agents access common locations. UMA adds a specific hardware placement relation and should not be inferred from shared access alone. Non-uniform Memory Access is the contrasting shared-memory architecture with processor-to-memory locality tiers; Intel's SNC description and the E25K near miss make the contrast concrete. Distributed Shared Memory offers a logical shared-data view over physically separate memories and is a different carrier and interface question.[1][4]

These are conceptual neighbors: shared access, exposed NUMA locality, and a distributed shared-memory interface each answer a different architectural question from whether main-memory placement has a near-versus-far tier inside one declared domain.

Relationships to Other Abstractions

Local relationship map for Uniform Memory AccessParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Uniform Memory AccessDOMAINPrime abstraction: Invariance — is part ofInvariancePRIME

Current abstraction Uniform Memory Access Domain-specific

Parents (1) — more general patterns this builds on

  • Uniform Memory Access is part of Invariance Prime

    A bounded requester/placement-invariant main-memory access class is the identity-bearing internal property of UMA.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Uniform Memory Access sits in a sparse region of the domain-specific corpus (98th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2721 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-17

Not to Be Confused With

  • NUMA: shared addressing with location-dependent near/far memory classes, rather than the absence of such classes inside the declared domain.[1][4]
  • Uniform cache-hit time: cache state and cache slice location are not the definition of a main-memory placement class.[1]
  • Constant observed latency or bandwidth: contention, queues and cache behavior may differ among operations even when the architectural main-memory location tier is absent.[3]
  • Shared or coherent CPU–GPU addressing: address sharing alone does not demonstrate processor-to-main-memory location uniformity.
  • All protected domains merged: Starfire's separate domains are separate shared-memory systems unless a more specific cross-domain arrangement is established.[2]

References

[1] Intel. (2022). "Technical Overview Of The Intel® Xeon® Scalable processor Max Series". https://www.intel.com/content/www/us/en/developer/articles/technical/xeon-scalable-processor-max-series.html. Describes the configured mode in sections "Uniform Memory Access Domain" and "Sub-NUMA Clustering"; this manufacturer article is not a benchmark establishing identical transaction latency. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u

[2] Alan Charlesworth et al., "The Starfire SMP interconnect" (1997), Proceedings of the 1997 ACM/IEEE Conference on Supercomputing, pp. 1–20. DOI: 10.1145/509593.509630. Describes the design in §§3 and 5; publisher record and abstract at https://doi.org/10.1145/509593.509630 and full original author text at the third-party mirror https://www.filibeto.org/~aduritz/truetrue/e10000/starfire-interconnect.html. The publisher full PDF was not independently inspected; the decisive same-board path is corroborated by the separate 1998 original below. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j

[3] Alan Charlesworth, "Starfire: Extending the SMP Envelope" (1998), IEEE Micro 18(1):39–49, DOI 10.1109/40.653032, full original article PDF at an academic host, especially printed p. 41 on same-board memory and board-independent access time. This is a distinct publication from the SC '97 paper. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r

[4] Sun Microsystems, Inc., "Sun Fire E25K/E20K Systems Overview" (2006). https://docs.oracle.com/cd/E19065-01/servers.e25k/817-4136-13/4_Interconnect.html. Describes the system interconnect in Chapter 4, §§4.1–4.5, Tables 4-2 and 4-3; manufacturer part number 817-4136-13. Its listed nanoseconds are calculated pin-to-pin interconnect latency classes under stated conditions, and E25K is a negative case distinct from Starfire. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p