Computing devices with independently consistent nodes

Abstract

A computing device includes two or more compute nodes, each compute node including two or more processor cores. Each compute node includes an independent coherent domain that is not coherent with other compute nodes. A central IO die is communicatively coupled to each of the two or more compute nodes. A plurality of locally attached volatile memory units are attached to the central IO die via one or more memory controllers. The central IO die includes one or more home agents for each compute node. The home agents are configured to map memory access requests received from the compute nodes to one or more addresses within the locally attached volatile memory units.

Description

Background Technology

[0001] Data centers typically comprise a large number of discrete computing nodes, such as server computers or other suitable computing devices. These devices can work independently and / or collaboratively to meet a variety of computing workloads. Sets of computing nodes can be grouped into a single package to share resources and reduce the distance between nodes. Summary of the Invention

[0002] This summary is provided to present a selection of concepts in a simplified form, which will be further described in the detailed description below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to the implementation of solutions to any or all of the shortcomings pointed out in any part of this disclosure.

[0003] The computing device comprises two or more computing nodes, each computing node comprising two or more processor cores. Each computing node includes an independently consistent domain inconsistent with the other computing nodes. A central I / O die is communicatively coupled to each of the two or more computing nodes. Multiple natively attached volatile memory cells are attached to the central I / O die via one or more memory controllers. The central I / O die includes one or more home agents for each computing node. The home agents are configured to map memory access requests received from the computing nodes to one or more addresses within the natively attached volatile memory cells. Attached Figure Description

[0004] Figure 1 Multiple compute nodes are schematically depicted and communicatively coupled to a discrete memory pool.

[0005] Figure 2 An example multi-node on-chip system with a central I / O die is illustrated schematically.

[0006] Figure 3 schematically shown Figure 2 An example computing node of the system.

[0007] Figure 4 An example cache organization architecture for an example compute node is illustrated schematically.

[0008] Figure 5 This is an example method for memory address mapping across multiple compute nodes.

[0009] Figure 6 An example data structure for mapping memory addresses across multiple compute nodes is illustrated schematically.

[0010] Figure 7schematically shown Figure 2 The system provides an example architecture for I / O chips.

[0011] Figure 8 An example consistent mapping for a computing system is illustrated schematically.

[0012] Figure 9A This schematically illustrates a traditional system for accessing I / O devices across multiple computing nodes.

[0013] Figure 9B A system for pooling I / O devices across multiple compute nodes, according to this disclosure, is illustrated schematically.

[0014] Figure 10 An example computing system is illustrated schematically. Detailed Implementation

[0015] As mentioned above, data centers typically comprise a large number of discrete computing nodes, such as server computers or other suitable computing devices. These computing nodes may be referred to as "host computing devices" or "hosts" because, in some cases, they can be used to host multiple virtual machines. However, it should be understood that computing nodes can be used for any suitable computing purpose and do not need to be specifically designed for hosting virtual machines. Furthermore, in some examples, computing nodes may be implemented as virtual machines.

[0016] Depending on the specific implementation, each individual compute node can have any suitable set of computer hardware. Regardless, each individual compute node will typically include a local set of hardware resources, including data storage, memory, processing resources, etc. However, compute workloads (e.g., those associated with data center customers) are often unevenly distributed across every compute node in the data center. Instead, in a common scenario, a subset of compute nodes in a data center may be assigned resource-intensive workloads while other compute nodes are idle or handling relatively few resource-intensive tasks. Therefore, the overall resource utilization of the data center may be relatively low; however, the completion of some workloads may be resource-limited due to how these workloads are located on individual nodes. This represents an inefficient use of available computing resources and is sometimes referred to as "resource stagnation" because computing resources potentially applicable to compute workloads are stagnant on idle or underutilized nodes.

[0017] This problem can be mitigated when hardware resources are removed from individual compute nodes and replaced by separate pools of resources that can be flexibly accessed by connected compute nodes. For example, this disclosure envisions scenarios where resources such as physical memory, I / O interfaces, caches, and virtualization resources are pooled together for use across all compute nodes in a system. For instance, volatile memory hardware (e.g., random access memory (RAM)) can be collected as part of a separate memory pool, for example, in a data center, from which any of the multiple compute nodes can access it. This helps alleviate resource congestion because compute nodes can freely request memory when needed and release it when no longer required.

[0018] This is about Figure 1 This is illustrated schematically. As shown, multiple compute nodes 100A-100N (where N is any suitable positive integer) are communicatively coupled to memory pool 102. In various examples, dozens, hundreds, thousands, or more individual compute nodes may share access to one or more discrete resource pools (including memory pool 102). As used herein, discrete memory can refer to physically separated memory elements and physically adjacent memory elements partitioned by a memory controller.

[0019] The discrete memory pool includes at least two memory control systems 104A and 104B, which manage and maintain sets of physical memory cells 106A and 106B, respectively. In this example, physical memory cell 106A is considered a natively attached physical memory cell, while physical memory cell 106 is considered a discrete memory cell. Memory control systems 104A and 104B can cooperate to provide a single discrete memory pool. However, in other examples, the discrete memory pool may include only one memory control system, or memory control systems 104A and 104B may operate independently of each other. As an example, the memory control system may be a serial bus interconnect-based programmable mode memory controller (PPMC) (e.g., a compute fast link (CXL) compliant pooled memory controller (CPMC)). For example, the physical memory cell may be any suitable type of volatile RAM, such as double data rate synchronous dynamic RAM (DDR SDRAM). The memory control system may facilitate the use of physical memory cells by any one or all of various compute nodes 100A-100N. It should be understood that a memory pool may include any appropriate number of physical memory cells corresponding to any appropriate total memory capacity, and may be managed by any number of different memory control systems.

[0020] Figure 1 A switch structure manager 108 is also schematically depicted. The switch structure manager can be configured to monitor and manage an entire computing environment, including multiple compute nodes and a memory pool 102. For example, the switch structure manager can set and apply policies that facilitate efficient and secure use of the memory pool by each of the multiple compute nodes. In some examples, the switch structure manager 108 can coordinate the operation of memory control systems 104A and 104B.

[0021] Traditionally, servers and compute nodes can be configured largely as self-sufficient entities, including processing resources, data storage, volatile / non-volatile memory, network interface components, power supplies, cooling solutions, etc. However, pooling resources across servers can be advantageous, for example, by consolidating internal power supplies, cooling systems, and / or network interfaces into a central rack. This can be used to reduce hardware redundancy, provide more resources (e.g., memory) to nodes that require them, and allow for unified management and balanced compute node prioritization using a centralized system.

[0022] Migrating such server clusters to silicon-on-a-chip (SoC) packaging may require balancing several seemingly disparate trends. On one hand, there is a trend toward integrating and building larger monolithic systems on silicon. Emerging cooling technologies allow for the operation of large server racks. Large, dense systems present opportunities to amortize fixed costs such as platform, rack, and cabling. However, the cost of maintaining consistency across large stack-count systems increases non-linearly. On the other hand, there is a need to appropriately scale modular systems to improve utilization. Most virtual machines use eight or fewer virtual CPUs. At any given time, up to 40% of the memory in a discrete memory pool is idle, unbound, and / or unused. Pooling accelerators, network interface controllers (NICs), and storage offers significant cost savings opportunities.

[0023] This disclosure presents a system for providing balanced, pooled memory (natively attached and decoupled) and I / O interfaces in a ruggedized, multi-node, chiplet-based SoC. An implementation of a multi-server-node on-chip system on a single package may include several chiplets or dices, each comprising several CPU cores and associated boot ports to independently run an OS and / or hypervisor. Compute nodes may share several external DDR channels and several internal high-bandwidth memory (HBM) channels accessible via a central I / O die, including multiple serial bus interconnect links. Each compute node and its internal cache are independently consistent, but not necessarily consistent with other compute nodes. This allows for partitioning and decoupling of locally connected memory, enabling different processing for each compute node even without physical decoupling from the chip. This implementation reduces manufacturing and maintenance costs compared to discrete implementations using traditional single-node and / or single-OS approaches.

[0024] Figure 2 An example computing device 200 is illustrated schematically. The computing device 200 may include one or more systems-on-a-chip (SoCs). However, the computing device 200 may also include other system configurations, such as multi-chip devices and a single server with central hardwired connections.

[0025] The computing device 200 can be considered a large, dense, discrete modular system characterized by dynamic pooling of all available I / O, memory capacity and bandwidth resources across multiple computing nodes 210.

[0026] Computing device 200 may include two or more computing nodes 210. As shown in the figure, computing device 200 includes eight computing nodes 210. Each computing node may include two or more processor cores, and each computing node may be an independent, consistent domain that is not consistent with the other computing nodes 210. Additional features of example computing nodes 210 are described herein and referenced. Figure 3 It was discussed.

[0027] Each compute node 210 can be configured to run an independent hypervisor that can be used to spawn and operate one or more virtual machines (VMs). The use of compute nodes as logical partition consistency domains enables modularity, allowing the compute device 200 to run multiple hypervisors simultaneously. This improves fault isolation by preventing cross-node overflows, thereby reducing the blast radius.

[0028] By separating the compute node 210 in this way, the computing device 200 can be provided with sufficient degrees of freedom to support two high-level operating modes. In some embodiments, the compute node 210 can actually be operated in a first operating mode, where the compute node 210 operates as a single consistent domain, similar to the current CPU.

[0029] However, independent consistency also enables each compute node 210 to be decoupled into its own operating domain, which has its own operating system that can be independently started and stopped, and which, from the perspective of any relevant software stack, functions in other ways like an independent system. This allows for a second operating mode in which each compute node 210 operates independently.

[0030] Therefore, each compute node in compute node 210 can be independently bootable and can be configured to independently run one of two or more operating systems (e.g., KBM, Hyper-V). In other words, any single compute node 210 can run an operating system that is different from the operating system run by each of the other compute nodes 210. This allows compute device 200 to run multiple operating systems simultaneously, thereby allowing targeted allocation to compute nodes 210 running the operating system most relevant and / or best suited to that allocation. The cores and caches within a single compute node 210 can be collectively consistent, even if they are inconsistent with the cores and caches in other compute nodes 210. However, in some implementations, two or more compute nodes 210 can form a consistent group, and / or two or more compute nodes 220 can run the same operating system simultaneously.

[0031] Typically, each compute node 210 must be supplied with its own set of resources. The topology or construction method described for compute device 200 allows for the pooling of some or all platform resources, making them available to all compute nodes 210 in compute device 200.

[0032] Such poolable platform resources include memory (both bandwidth and capacity), I / O (e.g., PCIe devices, accelerators, links, storage), and legacy platform components such as baseband management controllers, real-time clocks, and Trusted Platform Modules (TPMs). Pooling these resources allows computing device 200 to forgo replicating each component for each computing node 210, thereby enabling efficient use of pooled resources while maintaining power and cost constraints.

[0033] As an example, computing device 200 may also include a central I / O chip 220 communicatively coupled to each of two or more computing nodes 210, enabling pooling of platform resources among the computing nodes 210. Essentially, computing device 200 can be configured to use a multi-chip modular architecture with separate computing and I / O chiplets.

[0034] The central I / O die 220 may include all packaged I / O interfaces for the computing device 200, including a DDR interface 222 (solid line), a serial bus interconnect 224 (dashed line), a general purpose I / O (GPIO) interface 226, etc. Each of these I / O interfaces may include a multi-domain link shared for all robust partitions (e.g., compute node 210) to operate independently while maintaining the maximum available bandwidth to any CPU core (e.g., boot port, serial bus interconnect). The central I / O die 220 may also include a home agent (HA) 228 and a memory controller agent (MC) 230. In this way, each compute node 210 can utilize the provided functionality and receive supported access to connect to external devices. Additional components and structures of example central I / O dies are described herein and referenced. Figure 7 describe.

[0035] The central I / O die 200 therefore provides sufficient ports for serial bus interconnects to supply adequate connectivity for various external devices and allows for increased discrete memory bandwidth. The central I / O die 200 can virtually integrate a multi-node-aware serial bus switch, and the switch structure manager can also be integrated onto the central I / O die 200 for pooling of I / O devices in compute node 210. The central I / O die 200 can be configured to be unidirectionally consistent with each processor core, while the cache and memory serial buses can be configured to be bidirectionally consistent with each core.

[0036] In this example, several DDR channels are connected to the central I / O die 220 to be shared among all compute nodes 210 and their respective cores, so that all memory bandwidth and capacity are available at different times for each core of each compute node 210.

[0037] One or more natively attached volatile memory cells 240 are attached to a central I / O die 220 via a memory controller agent 230 and a DDR interface. The central I / O die 220 includes one or more home agents 228 for each compute node 210, configured to map memory access requests received from the compute node 210 to one or more addresses within the volatile memory cells 240. Each memory controller agent 230 may include one or more high-bandwidth memory channels configured to be shared between two or more compute nodes. Each memory controller may also operate one or more discrete caches as optional near-memory caches.

[0038] Furthermore, one or more discrete memory cells 242 are attached to the central I / O die 220 via a serial bus interconnect 224. A home agent 228 can also be configured to map memory access requests received from compute node 210 to one or more addresses within the discrete memory cells 242. The discrete memory cells 242 can be coupled to the central I / O die 220 via a PPMC controller 245 or other suitable memory controller that automatically accesses one or more discrete memory cells 242. Therefore, each compute node 210 can access each volatile memory cell in the natively attached volatile memory cells 240 and each memory cell in the discrete memory cells 242.

[0039] As shown in the figure, computing system 200 includes 12 channels of DDR5 RAM, including 8 channels of discrete memory cells 242 and 4 channels of natively attached volatile memory cells 240. As a non-limiting example, using a 64GB DIMM size, computing system 200 would include a total of 12 natively attached volatile memory cells for a total of 768GB, and a total of 64 discrete memory cells for a total of 1024GB, for a total RAM pool capacity of 1792GB.

[0040] The pooling and allocation of this memory can occur at the central I / O die 220. Access to natively attached volatile memory cells 240 can be faster than access to discrete memory cells 242 routed via the PPMC controller 245, and memory requests can be prioritized accordingly. Furthermore, discrete memory cells 242 can be physically separated and located at different physical locations relative to the central I / O die 220. Although natively attached volatile memory cells 240 are directly connected to the central I / O die 220, the memory cells themselves can still be considered discrete because different portions of each memory cell can be specifically allocated to any one of the multiple compute nodes. In some examples, one or more natively attached volatile memory cells 240 can be pooled for use by several compute nodes 210. Additionally or alternatively, regions of memory cells can be dedicated to one or more compute nodes 210 and not available to other compute nodes 210. In some examples, additional natively attached volatile memory cells can be provided with direct links and specifically dedicated to a single compute node 210.

[0041] Both the locally attached volatile memory unit 240 and the discrete memory unit 242 can be assigned or allocated to one or more compute nodes 210. The allocation of the locally attached volatile memory unit and the discrete memory unit can be based on at least one or more of the following: compute node-specific requirements, application-specific requirements, software-based policies, received requests from compute nodes for additional memory, and the availability of one or more of the locally attached volatile memory unit and the discrete memory unit. Memory reallocation can be performed periodically and / or in response to operating conditions (whether previous, current, or anticipated future conditions).

[0042] Furthermore, it is conceivable that various strategies can be employed when the amount of unallocated portions / slices of the locally attached volatile memory cells 240 and / or discrete memory cells 242 is low. In this case, the computing system 200 has fewer degrees of freedom to satisfy requests from the computing node 210 to receive larger memory allocations, for example, when such a computing node 210 starts or prepares for a more intensive computing task.

[0043] Mitigation strategies may include identifying a "memory pressure" situation (i.e., a low pool of available memory for locally attached volatile memory cells 240 and / or discrete memory cells 242) and then activating mechanisms for releasing memory cells. This typically involves revoking or cancelling memory currently reserved for compute node 210. Memory revocation may be based on a reference priority assessment, such as strategies to cover the least frequent or least recently used memory, or other assessments designed to minimize the harm or impact of memory revocation.

[0044] In some cases, revocation may include relocating the shifted data to another portion of discrete memory cell 242 managed by a different PPMC controller 245, or to a larger, higher-latency mass memory location. Thus, portions of one or more natively attached volatile memory cells are deallocated from the first compute node and reallocated to the second compute node under one or more of the following: node-specific requirements within the compute device, requests for multiple memory received from the second compute node, and the availability of one or more natively attached volatile memory cells and discrete memory cells. In some cases, mitigation may occur in the form of different types of memory. For example, a compute node 210 that has maximized the allocation of its natively attached volatile memory cells 240 and requested additional memory may receive an allocation of discrete memory cells 242.

[0045] Mitigation may additionally or alternatively include sending alerts to compute nodes (e.g., from native or pooled memory controllers, or from the switch structure manager or other infrastructure) to prompt them to help alleviate memory pressure. Such assistance from compute nodes may include nodes voluntarily relinquishing their holdings of native and / or discrete pooled memory, or delaying or avoiding requests for more memory that they might have made without pressure alerts.

[0046] Each discrete memory unit 242 may include multiple memory slices (e.g., 1GB slices), which can be allocated, unallocated, and reassigned to different compute nodes 210. The PPMC controller 245 can track each allocation, manage each slice, and route read / write access requests to the appropriate slice. The operation of the PPMC controller 245 can be regulated at least in part by a switch structure manager residing on the central I / O die 220.

[0047] In some examples, as described above, one or more slices of natively attached volatile memory units 240 may be allocated to a specific compute node 210 based on node-specific requirements. The allocated slices of natively attached volatile memory units 240 may require permission from the associated memory controller 230 for use. The memory controller 230 may then provide the allocated portion to the compute node 210. In some examples, based on the activity of one or more compute nodes 210 within the compute device 200, a portion of one or more volatile memory units of natively attached volatile memory units 240 may be deallocated from a first compute node and reallocated to a second compute node. Additionally or alternatively, the portion of natively attached volatile memory units allocated to the first compute node may be increased based on changes in node-specific requirements. Node-specific requirements may include, but are not limited to, node provisioning, the identification, type, number, and bandwidth of running programs and / or applications, the running operating system, the type and number of virtual machines being executed, whether the node is part of a node function group designated to perform a specific task in series, and the priority of compute node operations within the context of the entire compute node.

[0048] As described above, the locally attached volatile memory units 240 can be periodically or in response to operating conditions, and / or reallocated. The memory controller 230 can receive requests for additional allocations to the locally attached volatile memory units 240 and selectively grant extended memory allocations. For example, if two compute nodes 210 share a quota of locally attached volatile memory units 240, granting a request for additional allocations to the locally attached volatile memory units 240 from the first compute node can depend on requirements specific to the second compute node. For example, a node may be operating with a relatively high quality of service protocol and / or may be executing higher-priority applications or tasks.

[0049] Once allocated, each compute node 210 can determine how to manage its quota of natively attached volatile memory cells 240 and discrete memory cells 242. Although the relative latency may differ, the memory region for compute node 210 can include slices of both natively attached volatile memory cells 240 and discrete memory cells 242. Compute node 210 can preferentially use natively attached volatile memory cells 240 to reduce latency for specific tasks while allocating discrete memory cells 242 for less urgent tasks. In some examples, compute node 210 can interleave memory allocations to generate an average latency across all tasks.

[0050] In some examples, the amount of fragmented memory collectively allocated to multiple compute nodes 210 can exceed the amount of memory actually provided in the fragmented memory pool. This is sometimes referred to as “thin provisioning.” Typically, in data center environments without thin provisioning, it can be observed that over time, individual compute nodes 210 (and / or virtual machines implemented on compute nodes 210) are often provisioned with more resources (e.g., storage space, memory) than compute nodes 210 actually use. For example, in most cases, the amount of memory installed for a particular compute node 210 can be significantly higher than the amount of memory actually used by that compute node 210. When combined across multiple compute nodes 210, the amount of unused memory (or other resources) can represent a significant portion of the total memory (or other resources) in the data center.

[0051] In an example scenario without thin provisioning, the memory pool, comprising 1792GB of total memory, can be evenly distributed among the eight compute nodes 210. Thus, each compute node can be allocated 96GB of natively attached volatile memory units 240 and 128GB from discrete memory units 242, resulting in each node having a total of 224GB of provisioned memory allocated from the total pooled memory.

[0052] However, each compute node 210 is unlikely to fully utilize its memory allocation. Instead, in more common scenarios, each compute node 210 may only use up to 50% of its allocated memory during normal use, and some compute nodes 210 may use significantly less than 50% of the memory. Thus, even if the 1792GB fragmented memory pool is fully allocated to multiple compute nodes 210, only a relatively small portion of the pooled memory can be used at any given time, representing inefficient use of available resources.

[0053] With this in mind, the amount of memory actually available (i.e., “supplied”) in the total memory pool can be reduced without significantly impacting the performance of multiple compute nodes 210. While each particular compute node 210 may be allocated 96GB of natively attached volatile memory and 128GB of discrete memory, statistically, many compute nodes 210 will not use all or even most of any memory quota at any given time. Therefore, any unused natively attached volatile memory 240 allocated to a compute node 210 can be reallocated by the memory controller 230 to one or more of the other nodes 210, and any unused discrete memory 242 allocated to a compute node 210 can be reallocated by the PPMC 245 to one or more of the other nodes 210. In this way, since each compute node 210 typically does not use 224GB at any given time, any particular compute node 210 can choose to use up to 224GB of total memory if needed, while still retaining memory at least in the discrete memory pool.

[0054] This streamlined provisioning can be done to any suitable degree. Typically, it is generally beneficial to allocate more available memory than is typically used by the multiple compute nodes 210. In other words, if compute node 210 typically uses approximately 256GB, it is generally expected that more than 256GB of memory will be actually provided between natively attached memory and discrete memory, so that compute node 210 does not run out of available memory during normal use. However, in practice, any suitable amount of memory can be provisioned in a discrete memory pool, which can have any suitable relationship with the amount of memory allocated to the multiple compute nodes 210.

[0055] When thin provisioning is implemented, there may be situations where multiple compute nodes 210 attempt to share more memory than is available in the discrete memory pool. As described above, this can be referred to as “stressing” the discrete memory pool. Various measures can be taken to address this situation. For example, memory allocation can be stripped from one or more compute nodes 210 that are considered to have lower priority or lower demand for memory, whether they are natively attached volatile memory cells or discrete memory cells. Additionally or alternatively, memory requests for multiple compute nodes 210 can be routed to different discrete memory pools that may still have available memory, at the cost of higher latency. Since natively attached volatile memory cells 240 can be allocated by the memory controller 230 and / or the switching structure manager, and discrete memory cells 242 can be allocated by the PPMC 245, portions of natively attached, volatile, or discrete memory cells can be routed to compute nodes 210 based on node-specific requirements.

[0056] Requests for additional memory may have inherent preferences for memory types, and / or other parameters that may indicate priority and / or the priority of one memory type relative to another. For example, compute nodes may typically prefer natively attached volatile memory cells 240 over discrete memory cells 240 due to latency issues and / or the impact on other systems that may be coupled to discrete memory cells 242 via PPMC 245. However, this can be balanced with memory pressure on natively attached volatile memory cells 240 and limitations on the use of available memory (e.g., for natively attached volatile memory cells 240, longer operations that only need to retrieve results at a later time point may not be prioritized). However, when memory pressure needs to be relieved, discrete memory cells 242 may be reallocated first because the availability of the discrete memory pool is more important to the overall compute system 200, as this memory pool can be used to increase the overall liquidity and stability of the compute system 200.

[0057] Depending on the node-specific requirements, compute node 210 may request locally attached volatile memory cells, discrete memory cells 242, and / or general-purpose memory. For example, if compute node 210 experiences an increase in latency, it may request multiple locally attached memory cells. If memory controller 230 cannot fulfill such a request, it may forward the request to one or more PPMCs 245.

[0058] It is worth noting that the memory addressing techniques described in this paper can be implemented with or without a thin provisioning. In other words, the memory address mapping discussed in this paper can occur in the context of either a "thin" provisioning or a "thick" provisioning. Furthermore, both thick and thin provisioning techniques can be used in the same implementation.

[0059] Alternatively, each compute node 210 may be pre-allocated a certain amount of memory capacity in a split memory pool. If, and when, a particular compute node 210 fully fills its allocation and requests a larger allocation, node 210 may negotiate with the memory control system (e.g., PPMC 245) to determine whether compute node 210 should be allocated and how much additional split memory should be allocated, which may include reducing the allocation reserved for another compute node 210. In this way, the amount of memory capacity available in the split memory pool can be carefully balanced and divided among the multiple compute nodes 210 according to the actual needs of each compute node, rather than allowing each individual compute node 210 to acquire memory capacity it does not need.

[0060] In this way, one compute node 210 can be supplied with a different set of specific parameters and / or options than another compute node 210. For example, some compute nodes 210 may always require more memory capacity and bandwidth than other nodes. Furthermore, each compute node 210 can be presented with customized partitions of memory and I / O devices. Therefore, depending on the needs of the compute nodes 210 and the overall computing system 200, each compute node 210 can be provided with asymmetric access to and / or asymmetric mapping of resources. For example, if a first compute node requires local storage but a second compute node does not, the local storage allocated to the second compute node can be allocated to the first compute node. By centralizing resources that are typically statically provided at a central I / O die, each compute node can be effectively treated as a different type of hardware and / or firmware partition.

[0061] Go to Figure 3 An example compute node 300 is schematically shown. Compute node 300 may be an example of compute node 210. Compute node 300 is shown as being connected to a central I / O die 305 via a pair of high-speed serial interconnect links 310.

[0062] In this example, compute node 300 includes 32 cores 315 and 32 L3 caches 320, targeting 32 slice sets. However, other numbers of cores and caches are also possible. Figure 2The computing system shown has 8 nodes, which will therefore provide a total of 256 cores. However, with improvements in chip technology, the number of cores per computing node can be increased (e.g., 64 cores / node at 5nm and 128 cores / node at 3nm). As shown, 32 L3 caches 310 are interconnected in groups of 4 caches via one of the 8 interconnect hubs 325 within the computing node 300.

[0063] As described, core 315 is robustly partitioned from cores within other compute nodes. In this way, a reasonable die size 300 can be maintained for each compute node, thereby maximizing yield while minimizing power consumption. However, the partitioning of cores is not limited to a single compute node, and the total number of cores can be supplied and resupplyed as needed.

[0064] As the number of cores within a uniform domain increases, complexity increases non-linearly. Therefore, by maintaining a relatively small number of cores per compute node, system complexity is kept moderately low. This type of computing device is not constructed to support a very large VM, but rather built for multiple VMs, each with a finite number of cores (e.g., 32). VMs can be arbitrarily distributed across nodes.

[0065] Figure 4 An example cache organization architecture for example compute node 400 is schematically illustrated. Compute node 400 can be an example of compute nodes 210 and 300. The compute node includes multiple cores 410 (e.g., 32 cores as shown in compute node 300). Each core 410 may include a dedicated cache for instructions (I cache 412), a data cache (D cache 414), and an associated core-specific L2 cache 416. Furthermore, each core 410 may include one or more shared distributed L3 caches 420. Figure 3 As shown, for a 32-core compute node, each core can be paired with a shared L3 cache, and each L3 cache can be accessed by each core of the compute node. Cache coherence between the L3 caches of the compute nodes is managed using any suitable method. Each compute node 400 can also access DDR memory 425 via address interleaving decoding 430 of the central I / O die. (See also: ...) Figure 2 As described, one or more separate caches can be coupled to each memory controller.

[0066] Each compute node, as a separate hardware partitioned machine, has its own internal understanding of address mapping for memory locations within the node. However, for multiple compute nodes with potentially identical configurations within a single computing system, the central I / O daemon can use packet physical addresses to distinguish the host physical address for each node.

[0067] Figure 5 An example method 500 for memory address mapping across multiple compute nodes is shown. Method 500 can be executed by the logic core of the central I / O die of a multi-compute-node computing system.

[0068] At 510, method 500 includes receiving a memory access request, including a host physical address for the first compute node, from a central I / O die communicatively connected to two or more independent, coherent compute nodes. Typically, the host physical address refers to an internal identifier of a specific compute node for a specific memory address within a larger address space of the node. Reads and writes to a particular HPA may ultimately terminate at a physical memory cell (e.g., a RAM DIMM) in a discrete memory pool.

[0069] At 520, method 500 includes mapping the host physical address for the received request to a system address map, the system address map including a range of host physical addresses for each of two or more independently coherent compute nodes. This may include, for example, receiving an indication of one or more HPA ranges from each of a plurality of compute nodes communicatively coupled to a central I / O die.

[0070] As an example, Figure 6 An example data structure 600 for mapping memory addresses across multiple compute nodes is schematically depicted. Data structure 600 schematically illustrates the relationship between the host physical address seen by each node and the packet physical address seen by the central I / O die. A first compute node (e.g., compute node 0) maps host physical addresses to a first range 605. Each additional node maps host physical addresses to an additional range (e.g., compute node 7 maps to range 610), such that each host physical address is mapped into the packet physical address space. In this example, the system address mapping comprises contiguous stacked address boards of equal length for each of two or more nodes, where each board corresponds to a host physical address range for the respective node. In this example, each compute node includes 16 banks of host physical addresses. In some examples, the range of host physical addresses is interleaved between available home agents and memory channels included in the I / O die. In this way, each compute node can be provided with access to the full memory bandwidth.

[0071] return Figure 5 At 530, method 500 includes outputting packet physical addresses based on the mapped host physical address. For example, Figure 6The range of packet physical addresses 615 is shown, which includes each host physical address for each compute node (e.g., compute nodes 0-7). In some examples, the packet physical address includes a node ID appended to the host physical address (e.g., 0-7). This can be achieved by requisitioning the address bits above to insert the node ID when a request is made to enter the I / O die. In other words, the node ID can act as a valid region code within the compute node for the host physical address.

[0072] At 540, method 500 includes mapping packet physical addresses to physical elements that are selectively coupled to memory cells of the first compute node via a central I / O die. This mapping may include DIMMs, banks, bank groups, rows, and columns that map packet physical addresses to specific RAM cells. In some cases, the mapping of memory addresses to physical memory cells may be controlled by a switching structure manager to prevent any individual compute node or memory control system from compromising the overall environment.

[0073] At 550, method 500 includes providing a first compute node access to the physical element of the memory cell. For example, the access can be provided using a packet physical address, as this refers to all addressable physical memory elements throughout the compute system. In some examples, when the memory cell is located outside the compute system, the associated memory controller may be interconnected to multiple packets. Thus, a packet identifier can be appended to the packet physical address to allow the memory controller to distinguish between requests.

[0074] In addition to mediating access to discrete memory and cache, the central I / O die can be used to pool and distribute access to I / O devices for each compute node, thereby linking compute nodes to all out-of-package interfaces. Figure 7 A more detailed mapping of a computing system 700 with a central I / O die 705 is shown. The computing system 700 and the central I / O die 705 can be examples of computing system 200 and central I / O die 220.

[0075] A central I / O die 705 is coupled to eight compute nodes 710 via a dedicated compute die port (CDP) 715 and at least one dedicated boot port 717 for each compute node 710, allowing each compute node 710 to be booted independently using its own operating system or hypervisor. Each CDP 715 is linked to a home agent (HA) 720. Each HA 720 maintains information about the internal addresses of its respective connected compute nodes. Thus, the HA 720 is responsible for the consistency and management of memory resources for the compute nodes 710. Due to bandwidth constraints, multiple HAs 720 are provided to distribute their workloads. These interconnected HAs 720s distribute access received from the compute nodes 710, thereby reducing hotspot occurrences. This paper combines... Figure 8 Additional descriptions for Home Agent 720 are provided.

[0076] From each HA 720, when a request for access to a specific memory element is made, the HA 720 decodes which memory controller the memory element is mapped to. In some examples, the memory element may be mapped to one of a plurality of memory controllers 725 that are locally attached to DDR memory (e.g., via DDR interface 727, solid line) and configured to selectively couple each compute node 710 to one or more locally attached volatile memory cells. Additionally or alternatively, the memory element may be mapped to one of a plurality of pooled PPMCs coupled to a Serial Bus Interconnect (SBI) 730 at a separate location (e.g., via dashed line 732) to selectively couple each compute node to one or more discrete memory cells.

[0077] The switch structure manager 735 can be configured to mediate pooling of all I / O devices (including memory) across compute nodes 710. The switch structure manager 735 can mediate the binding of each processor, core, compute node, etc., to the hardware components and ports of the central I / O die 705. Since different compute nodes 710 can have different configurations and requirements, this binding may be unbalanced. A mesh-based die interconnect 740 can be used to couple each of these components of the central I / O die 705. I / O ports (IOPs) 750 can mediate traffic from external components, ensuring that I / O direct memory access (DMA) traffic remains on the central I / O die after being converted from the input / output memory management unit (IOMMU) within each IOP.

[0078] At each CDP 715, traffic to and from the associated compute node 710 can be metered, thereby allowing the provision of information such as... Figure 2 The described memory bandwidth allocation and prioritization of traffic from external I / O devices allow for different levels of service and resource allocation to different compute nodes 710. (See also: Regarding...) Figure 2As described, for memory capacity partitioning, individual compute nodes 710, and even individual cores within each compute node 710, can be brought online, allowing memory to be allocated differently across different hosts. In conjunction with the CDP 715, the switch structure manager 735 can use machine learning principles to determine when and whether certain compute nodes 710 need a larger memory allocation, and which compute nodes 710 can release at least a portion of their current allocation. The switch structure manager 735 can be configured with policies, such as those that automatically activate, to determine the upper and lower limits of VM utilization, thus providing larger resource allocation shares. Additionally or alternatively, policies can be set to fix partitions so that compute nodes cannot exceed their allocation, even if other VMs are currently idle.

[0079] Figure 8 An example consistency mapping for computing system 800 is shown. Computing system 800 can be an example of computing systems 200 and 700, and is shown in a simplified form with a single computing node 805 connected to a central I / O die 810. Computing node 805 is shown as being coupled to a home agent 810 via a computing die port (CDP) 812. The home agent (HA) 814 is coupled to I / O port 815 and memory controller 817, which in turn is coupled to DDR RAM 820. HA 810 can be considered as the center of consistency management in the central I / O die 810.

[0080] When a request is received from compute node 805 via CDP 812, CDP 812 decodes the address within the request and determines which of the distributed HAs within central I / O die 810 should receive the request (e.g., by mapping to a packet physical address). Once directed to HA 810, the request is passed to Destination Address Decoder (TAD) 825. TAD 825 is responsible for mapping the request to a destination. For example, if a memory access request is received, TAD 825 determines whether the request is for natively attached DDR. If so, the request is sent to memory controller 817 and the specific DDR 820 it is mapped to. Alternatively, if the memory access request is for discrete memory, the request is sent to memory port 827 within I / O port 815, and then to external device 830 hosting discrete memory 832.

[0081] Furthermore, the HA 810 includes a cache currency mechanism 835, which can be viewed as a set of snooping filters. Such snooping filters allow the HA 810 to ensure that accesses are current cache entries and do not violate any currency rules. Thus, if a requested updated copy exists in Content Addressable Memory (CAM) 837, the snooping filters (SFs) (e.g., sector SF 840, SBI$SF 841, IO$SF 842) will discover the updated copy from compute node 805, IO Wr$844, and external cache 845, respectively, and present it for retrieval.

[0082] HA 810 also handles requests from external devices, such as PCIe devices configured to perform reads and / or writes to memory. Such requests can originate from logic within external device 830 and be sent to SBI root port 847. Root port 847 can then, for example, use IOMMU 850 to translate the I / O virtual address sent by external device 830 into a known physical address. This address can then be decoded and sent to HA 810. I / O logic 852 can perform this decoding using one or more hash functions (e.g., the same hash function present in CDP 812) such that any request for a given address ends with the same HA, thus maintaining versatility. HA 810 can then translate the requested address for the external device. I / O port 815 may also include SBI$ port 855, allowing parallel lookups of external cache 845 and discrete memory 832.

[0083] Figure 9AA conventional system 900 for accessing I / O devices across multiple compute nodes is schematically illustrated. In system 900, each compute node (e.g., node 902 and node 903, although more may be included) operates multiple virtual machines (e.g., VM 904, VM ​​905, VM 906, VM 907, VM 908, VM 909). Most virtual machines operate in conjunction with virtual functions (e.g., VF driver 916, VF driver 917, VF driver 918, VF driver 919) hosted by network interface controllers (NICs) (e.g., NIC 914 and NIC 915) (e.g., VF 910, VF 911, VF 912, VF 913). Each compute node includes a virtual machine (e.g., VM 906, VM 909), which is co-operated by the NIC with physical functions (e.g., physical functions 923, physical functions 924) managed by PF drivers (e.g., PF drivers 925, PF drivers 926) of the virtual machine manager (e.g., VMM 927, VMM 928) for the respective node, and virtual NICs (e.g., virtual NIC 920 and virtual NIC 921). Physical functions 923 and 924 can perform the functions of a network adapter supporting a single root I / O virtualization (SR-IOV) interface, which can be used to pair nodes and NICs via IOMMU 926.

[0084] Each NIC represents a device that includes highly partitionable interfaces for software and may include multiple virtual functions (910, 911, 912, 913) that can be directly assigned to software entities (e.g., virtual machines 904, 905, 907, and 908) for direct management. However, in this configuration, direct management is limited to generating n virtual machines within a single physical machine, where each of the n virtual machines receives virtual functions from a dedicated NIC.

[0085] Figure 9BA system 950 for pooling I / O devices across multiple compute nodes, according to this disclosure, is schematically illustrated. In system 950, each compute node (e.g., node 952 and node 953, although more may be included) operates multiple virtual machines (e.g., VM 954, VM ​​955, VM 956, VM 957, VM 958, VM 959). Most virtual machines operate in conjunction with virtual functions (e.g., VF driver 966, VF driver 967, VF driver 968, VF driver 969, VF driver 970) hosted by a single NIC 966. Each compute node includes a virtual machine (e.g., VM 956, VM 959), which is co-operated by NIC 966 with virtual NICs (e.g., virtual NIC 971 and virtual NIC 972) using physical functions (e.g., physical function 973) hosted via PF drivers (e.g., PF driver 975, PF driver 976) of the virtual machine manager (e.g., VMM 977, VMM 978) for the respective node.

[0086] Unlike System 900, instead of providing a NIC for each compute node, a single NIC 966 is pooled across nodes 952 and 953 via IOMMU 980 and Switching Schema Manager 982. The SR-IOV principle can be used for pooling, and the virtual hierarchy scheme can be defined by the serial bus interface specification.

[0087] To achieve this, the switch structure manager 982 can be configured to possess the physical functionality of each device while binding virtual functionality to individual nodes. All downstream configuration and I / O requests can be captured at the switch structure manager 982 until a response can be emulated. Furthermore, the switch structure manager 982 can be programmed against the host I / O bridge to append node IDs (such as those related to address translation services) to upstream untranslated requests and address translation service responses. Figure 5 and Figure 6 (As described).

[0088] In some embodiments, the methods and processes described herein may be construed as computing systems of one or more computing devices. In particular, such methods and processes may be implemented as computer applications or services, application programming interfaces (APIs), libraries, and / or other computer program products.

[0089] Figure 10A non-limiting embodiment of a computing system 1000, capable of implementing one or more of the methods and processes described above, is illustrated schematically. The computing system 1000 is shown in a simplified form. The computing system 1000 may take the form of one or more personal computers, server computers, tablet computers, home entertainment computers, network computing devices, gaming devices, mobile computing devices, mobile communication devices (e.g., smartphones), and / or other computing devices.

[0090] The computing system 1000 includes a logic machine 1010 and a memory machine 1020. The computing system 1000 may optionally include a display subsystem 1030, an input subsystem 1040, a communication subsystem 1050, and / or... Figure 10 Other components not shown.

[0091] The logic machine 1010 includes one or more physical devices configured to execute instructions. For example, the logic machine may be configured to execute instructions that are part of one or more applications, services, programs, routines, libraries, objects, components, data structures, or other logical constructs. Such instructions may be implemented to perform tasks, implement data types, transition the state of one or more components, achieve technical effects, or otherwise obtain desired results.

[0092] A logic machine may include one or more processors configured to execute software instructions. Additionally or alternatively, a logic machine may include one or more hardware or firmware logic machines configured to execute hardware or firmware instructions. The processor of the logic machine may be single-core or multi-core, and the instructions executed thereon may be configured for sequential, parallel, and / or distributed processing. The various components of the logic machine may optionally be distributed across two or more independent devices that can be remotely located and / or configured for coordinated processing. Aspects of the logic machine may be virtualized and executed by remotely accessible, networked computing devices configured in a cloud computing configuration.

[0093] The storage device 1020 includes one or more physical devices configured to store instructions executable by a logic machine. When such methods and processes are implemented, the state of the storage device 1020 can be changed, for example, to store different data.

[0094] Storage device 1020 may include removable and / or built-in devices. Storage device 1020 may include optical storage (e.g., CD, DVD, HD-DVD, Blu-ray disc), semiconductor storage (e.g., RAM, EPROM, EEPROM), and / or magnetic storage (e.g., hard disk drive, floppy disk drive, tape drive, MRAM), etc. Storage device 1020 may include volatile, non-volatile, dynamic, static, read / write, read-only, random access, sequential access, location-addressable, file-addressable, and / or content-addressable devices.

[0095] It should be understood that the memory 1020 includes one or more physical devices. However, aspects of the instructions described herein may alternatively be propagated by a communication medium (e.g., electromagnetic signals, optical signals) that is not maintained by the physical devices for a finite duration.

[0096] Various aspects of the logic machine 1010 and the memory machine 1020 can be integrated together into one or more hardware logic components. For example, such hardware logic components may include field-programmable gate arrays (FPGAs), application-specific integrated circuits (PASICs / ASICs), application-specific standard products (PSSPs / ASPs), system-on-a-chip (SoCs), and complex programmable logic devices (CPLDs).

[0097] The terms "module," "program," and "engine" can be used to describe an aspect of a computing system 1000 implemented to perform a specific function. In some cases, a module, program, or engine can be instantiated via a logic machine 1010 that executes instructions maintained by a memory machine 1020. It should be understood that different modules, programs, and / or engines can be instantiated from the same application, service, code block, object, library, routine, API, function, etc. Similarly, the same module, program, and / or engine can be instantiated from different applications, services, code blocks, objects, routines, APIs, functions, etc. The terms "module," "program," and "engine" can include a single executable file or a group of executable files, data files, libraries, drives, scripts, database records, etc.

[0098] It should be understood that the term "service" as used in this article refers to an application that can execute across multiple user sessions. A service can be used for one or more system components, programs, and / or other services. In some implementations, a service can run on one or more server computing devices.

[0099] When included, the display subsystem 1020 can be used to present a visual representation of the data maintained by the storage unit 1020. This visual representation may take the form of a graphical user interface (GUI). Since the methods and processes described herein change the data maintained by the storage unit and thus transform the state of the storage unit, the state of the display subsystem 1030 can also be translated into a visual representation of the changes in the underlying data. The display subsystem 1030 may include one or more display devices utilizing virtually any type of technology. Such display devices may be combined with the logic unit 1010 and / or the storage unit 1020 in a shared enclosure, or such display devices may be peripheral display devices.

[0100] When included, the input subsystem 1040 may include one or more user input devices, such as a keyboard, mouse, touchscreen, or game controller, or interface with one or more user input devices. In some embodiments, the input subsystem may include or interact with selected Natural User Input (NUI) components. Such components may be integrated or peripheral, and the translation and / or processing of input actions may be on-board or off-board. Example NUI components may include microphones for voice and / or speech recognition; infrared, color, stereo, and / or depth cameras for machine vision and / or gesture recognition; head trackers, eye trackers, accelerometers, and / or gyroscopes for motion detection and / or intent recognition; and electric field sensing components for assessing brain activity.

[0101] When included, the communication subsystem 1050 can be configured to communicatively couple the computing system 1000 to one or more other computing devices. The communication subsystem 1050 may include wired and / or wireless communication devices compatible with one or more different communication protocols. As a non-limiting example, the communication subsystem can be configured to communicate via a wireless telephone network or a wired or wireless local area network or wide area network. In some embodiments, the communication subsystem may allow the computing system 1000 to send and / or receive messages from other devices via a network such as the Internet.

[0102] In one example, the computing device includes two or more computing nodes, each computing node including two or more processor cores, each computing node including an independently consistent domain inconsistent with the other computing nodes; a central I / O die communicatively coupled to each of the two or more computing nodes; and a plurality of natively attached volatile memory cells attached to the central I / O die via one or more memory controllers, wherein the central I / O die includes one or more home agents for each computing node, the home agents being configured to map memory access requests received from the computing nodes to one or more addresses within the natively attached volatile memory cells. In such an example or any other example, the computing device additionally or alternatively includes one or more discrete memory cells interconnected via a serial bus and attached to the central I / O die, wherein the home agents are also configured to map memory access requests received from the computing nodes to one or more addresses within the discrete memory cells. In any of the foregoing examples or any other examples, each computing node additionally or alternatively has access to each natively attached volatile memory cell and each discrete memory cell. In any of the foregoing examples or any other examples, based on one or more requests received from a first compute node for multiple memories and the availability of one or more locally attached volatile memory cells and discrete memory cells, portions of one or more locally attached volatile memory cells are additionally or alternatively allocated to the first compute node. In any of the foregoing examples or any other examples, portions of one or more locally attached volatile memory cells are additionally or alternatively allocated to the first compute node based on node-specific requirements. In any of the foregoing examples or any other examples, based on node-specific requirements within the computing device, portions of one or more locally attached volatile memory cells are additionally or alternatively disposed of from the first compute node and reassigned to a second compute node. In any of the foregoing examples or any other examples, based on a request received from a second compute node for multiple memories, portions of one or more locally attached volatile memory cells are additionally or alternatively disposed of from the first compute node and reassigned to the second compute node. In any of the foregoing examples or any other examples, based on the availability of one or more of the natively attached volatile memory cells and discrete memory cells, a portion of one or more of the natively attached volatile memory cells is additionally or alternatively disposed from the first compute node and reassigned to the second compute node.In any of the foregoing examples or any other examples, one or more discrete caches are additionally or alternatively coupled to each memory controller. In any of the foregoing examples or any other examples, each memory controller additionally or alternatively includes one or more high-bandwidth memory channels configured to be shared between two or more compute nodes.

[0103] In another example, a computing device including a system-on-a-chip includes two or more computing nodes, each computing node including two or more processor cores, each computing node including an independently coherent domain inconsistent with the other computing nodes; and a central I / O die, communicatively coupled to each of the two or more computing nodes via dedicated computing die ports, the central I / O die including: one or more native memory interfaces attached to one or more memory controllers, the native memory interfaces selectively coupling each computing node to one or more natively attached volatile memory cells; one or more interconnects to selectively couple each computing node to one or more discrete memory cells in discrete memory cells; one or more connectivity links for selectively coupling the two or more computing nodes to one or more external devices; and a switch structure manager configured to mediate pooling of all I / O devices among the two or more computing nodes. In such an example or any other example, the central I / O die additionally or alternatively includes all packet I / O interfaces for the two or more computing nodes. In any of the foregoing examples or any other examples, the central I / O die additional or alternative ground includes a multi-node-aware serial bus interconnect switch, configured to pool I / O devices connected to the central I / O die across two or more compute nodes. In any of the foregoing examples or any other examples, the pooling of I / O devices is managed using a pooled single root I / O virtualization (SR-IOV) interface additional or alternative ground. In any of the foregoing examples or any other examples, the pooled SR-IOV interface additional or alternative ground includes a single network interface controller (NIC) coupled to each compute node via a switch fabric manager and an input / output memory management unit (IOMMU). In any of the foregoing examples or any other examples, the switch fabric manager additional or alternative ground is configured to possess the physical functionality of the NIC and bind the virtual functionality hosted by the NIC to the individual compute nodes.

[0104] In yet another example, a method for memory address mapping includes: receiving a memory access request, including a host physical address for the first compute node, from a first compute node at a central I / O die communicatively connected to two or more independent, coherent compute nodes; mapping the host physical address for the received request to a system address map, the system address map including a range of host physical addresses for each of the two or more independent, coherent compute nodes; outputting a packet physical address based on the mapped host physical address; mapping the packet physical address to a physical element of a memory cell of the first compute node selectively coupled via the central I / O die; and providing first compute node access to the physical element of the memory cell. In such an example or any other example, the system address map additionally or alternatively includes a contiguous address board of equal length for each of the two or more nodes. In any of the foregoing examples or any other examples, the packet physical address additionally or alternatively includes a node ID appended to the host physical address. In any of the foregoing examples or any other examples, the range of host physical addresses is additionally or alternatively interleaved between available home agents and memory channels included in the central I / O die.

[0105] It should be understood that the configurations and / or methods described herein are exemplary in nature, and these specific embodiments or examples should not be considered limiting, as many variations are possible. The specific routines or methods described herein may represent one or more of any number of processing strategies. Thus, the various actions shown and / or described may be performed in the shown and / or described order, in a different order, in parallel, or omitted. Similarly, the order of the above processing may be changed.

[0106] The subject matter of this disclosure includes all combinations and sub-combinations of various processes, systems and configurations, as well as other features, functions, actions and / or attributes disclosed herein, and any and all equivalents.

Claims

1. A computing device, comprising: Two or more compute nodes, each compute node including two or more processor cores, each compute node including an independent consistent domain inconsistent with other compute nodes; A central I / O die, which is communicatively coupled to each of the two or more compute nodes; as well as Multiple natively attached volatile memory cells are attached to the central I / O die via one or more memory controllers, wherein the central I / O die includes one or more home agents for each compute node, the home agents being configured to map memory access requests received from the compute node to one or more addresses within the natively attached volatile memory cells, such that each compute node can access each natively attached volatile memory cell, and that portions of one or more natively attached volatile memory cells are allocated and reallocated among compute nodes based on node-specific requirements.

2. The computing device according to claim 1, further comprising: One or more discrete memory cells are attached to the central I / O die via serial bus interconnection, wherein the home agent is further configured to map memory access requests received from the compute node to one or more addresses within the discrete memory cells.

3. The computing device of claim 2, wherein each computing node is capable of accessing each of the discrete memory cells in the discrete memory cells.

4. The computing device of claim 3, wherein a portion of one or more of the natively attached volatile memory cells is allocated to the first computing node based on one or more requests for more memory received from the first computing node and the availability of one or more of the natively attached volatile memory cells and discrete memory cells.

5. The computing device of claim 1, wherein portions of one or more of the natively attached volatile memory cells are disposed of from the first computing node and reassigned to the second computing node based on a request for more memory received from the second computing node.

6. The computing device of claim 1, wherein a portion of one or more of the natively attached volatile memory cells is disposed from the first computing node and reassigned to the second computing node based on the availability of one or more of the natively attached volatile memory cells and the discrete memory cells.

7. The computing device of claim 1, wherein one or more discrete caches are coupled to each memory controller.

8. The computing device of claim 1, wherein each memory controller includes one or more high-bandwidth memory channels configured to be shared between the two or more computing nodes.

9. A computing device including a system-on-a-chip, comprising: Two or more compute nodes, each compute node including two or more processor cores, each compute node including an independent consistent domain inconsistent with other compute nodes; as well as A central I / O die, communicatively coupled to each of the two or more compute nodes via a dedicated compute die port, the central I / O die comprising: One or more native memory interfaces are attached to one or more memory controllers, which selectively couple each compute node to one or more natively attached volatile memory cells; One or more interconnects that selectively couple each computing node to one or more discrete memory cells; One or more connectivity links that selectively couple the two or more computing nodes to one or more external devices; and The switching structure manager is configured to mediate the pooling of all I / O devices across the two or more compute nodes.

10. The computing device of claim 9, wherein the central I / O die includes all packaged I / O interfaces for the two or more computing nodes.

11. The computing device of claim 10, wherein the central I / O die further comprises a multi-node-aware serial bus interconnect switch configured to pool I / O devices connected to the central I / O die across the two or more computing nodes.

12. The computing device of claim 10, wherein the pooling of the I / O devices is managed using a pooled single root I / O virtualization SR-IOV interface.

13. The computing device of claim 12, wherein the pooled SR-IOV interface comprises a single network interface controller (NIC) coupled to each of the computing nodes via a switching structure manager and an input / output memory management unit (IOMMU).

14. The computing device of claim 13, wherein the switching structure manager is configured to possess the physical functions of the NIC and bind virtual functions hosted by the NIC to the respective computing nodes.

15. A method for memory address mapping, comprising: At the central I / O die communicatively connected to two or more independent and consistent computing nodes, a memory access request including the host physical address of the first computing node is received from the first computing node. The host physical address for the received request is mapped to a system address mapping, the system address mapping including a range of host physical addresses for each of the two or more independent and consistent compute nodes. Output packet physical address based on the mapped host physical address; The packet physical address is mapped to the physical element of the memory cell, and the physical element of the memory cell is selectively coupled to the first computing node via the central I / O die; as well as Provide the first computing node access to the physical element of the memory cell.

16. The method of claim 15, wherein the system address mapping comprises contiguous address boards of equal length for each of the two or more nodes.

17. The method of claim 15, wherein the packet physical address includes a node ID appended to the host physical address.

18. The method of claim 15, wherein the range of the host physical address is interleaved among the available home agents and memory channels included in the central I / O die.

Images