Patent Description:
The present disclosure provides an interconnect to optimize remote access performance in NUMA platforms. Conventionally, memory bandwidth for NUMA platforms is referenced based on local memory access. For example, NUMA memory bandwidth for a multi-processor platform with 256GB/sec peak memory bandwidth is calculated by the following formula: (<NUM> GT/s* <NUM> bytes per channel x N channels x M sockets). Although such a memory bandwidth might be suitable for local systems it is not suitable for other systems, such as those incorporating enterprise and/or cloud computing applications (e.g., big data analytics, content management, databases, or the like). In practice, remote memory access bandwidth for NUMA platforms is substantially less than that published by vendors and in many cases can be as little as <NUM>% of the peak bandwidth.

Thus, the present disclosure provides an interconnect for a NUMA platform to improve data transfer efficiency by run-time profiling. With some examples, the interconnect can provide integrated compression and decompression capability into the interconnect itself. In some examples, the present disclosure provides a profile guided algorithm to control data compression and transfer. As a result, interconnects according to the present disclosure can not only dynamically maximizes interconnect data transfer efficiency but also provide flexibility to adapt to different applications or different memory access behavior patterns.

<FIG> is an example block diagram of a system <NUM> that may incorporate embodiments of the present disclosure. In general, <FIG> is illustrative of a computing platform comprising a NUMA architecture to carry out aspects of the technical processes described herein, and does not limit the scope of the claims. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. In one embodiment, the system <NUM> typically includes multiple compute sockets, such as compute socket <NUM> and compute socket <NUM> coupled together via an interconnect <NUM>.

Each compute socket (e.g., compute socket <NUM> and compute socket <NUM>) includes a processor <NUM> coupled to memory <NUM> via bus <NUM>. In particular, each processor <NUM> can be coupled to multiple memory <NUM> devices via a respective bus <NUM>. To facilitate memory access, processor <NUM> can include an integrated memory controller <NUM>. In particular, each processor <NUM> can include an integrated memory controller <NUM> for each respective bus <NUM> to which the processor <NUM> accesses memory <NUM>.

Each processor <NUM> can include a multi-threaded processor or a multi-core processor (whether the multiple cores coexist on the same or separate dies). Further, each processor <NUM> need not be identical. In some examples, processor <NUM> may include graphics processing portions and may include dedicated memory, multiple-threaded processing and/or some other parallel processing capability. In some examples, the processor <NUM> may be an application specific integrated circuit (ASIC) or a field programmable integrated circuit (FPGA). In some implementations, the processor <NUM> may be circuitry arranged to perform particular computations, such as, related to artificial intelligence (Al) or graphics. Such circuitry may be referred to as an accelerator.

Memory <NUM> can be a tangible media configured to store computer readable data and instructions. Examples of tangible media include circuitry for storing data (e.g., semiconductor memory), such as, flash memory, non-transitory read-only-memory (ROMS), dynamic random access memory (DRAM), NAND memory, NOR memory, phase-change memory, battery-backed volatile memory, or the like. Memory <NUM> may often be referred to as "main memory. " For example memory <NUM> in compute socket <NUM> may be referred to as main memory, or local memory, for processor <NUM> in compute socket <NUM>. Likewise, memory <NUM> in compute socket <NUM> may be referred to as main memory, or local memory, for processor <NUM> in compute socket <NUM>. However, memory <NUM> in compute socket <NUM> may be referred to as remote memory for processor <NUM> in compute socket <NUM>. Similarly, memory <NUM> in compute socket <NUM> may be referred to as remote memory for processor <NUM> in compute socket <NUM>.

Compute socket <NUM> and compute socket <NUM> may be coupled via an interconnect link <NUM>. In general, interconnect link <NUM> can be any of a variety of circuits arranged to provide transmission and receipt of data via interconnect <NUM>. For example, interconnect <NUM> can be a transport interconnect, such as, for example, the QuickPath Interconnect® (QPI) or the Ultra Path Interconnect® (UPI) by Intel® Corp. As another example, interconnect <NUM> can be the Kaizer Technology Interconnect® (KTI) by Intel® Corp. With still other examples, the interconnect <NUM> can be the HyperTransport® interconnect by AMD® Corp.

Although not shown, in some examples, each processor <NUM> can include multiple interconnect link <NUM> to couple to more than one compute socket. For example, <FIG> depicts a two socket (<NUM>) configuration. The present disclosure can be implemented in systems with greater than two sockets, such as, for example, a four socket (<NUM>) configuration (e.g., see <FIG>), an eight socket (<NUM>) configuration, or the like.

It will be readily apparent to one of ordinary skill in the art that the system <NUM> may be a device such as a mobile device, a desktop computer, a laptop computer, a rack-mounted computer system. Further, system <NUM> can be server system, such as, deployed in a data center or other enterprise environment and utilized for various workloads (e.g., cloud compute, database, content management, or the like).

Interconnect link <NUM> comprises circuitry to provide remote access to memory according to examples of the present disclosure. For example, interconnect link <NUM> can provide access to memory in another compute socket. More particularly, interconnect link <NUM> of processor <NUM> of compute socket <NUM> can provide access to memory <NUM> of compute socket <NUM> via interconnect <NUM>. Further, interconnect link <NUM> can provide remote memory access via an input/output (I/O) device (not shown) coupled to I/O controller <NUM>.

With some examples, the circuitry for interconnect link <NUM> can be incorporated into the die of processor <NUM>. Furthermore, with some examples, the circuitry for interconnect link <NUM> can include circuitry arranged to communicate via interconnect <NUM> and to compress and decompress data communicated via the interconnect bus. In some examples, interconnect link <NUM> can compress and decompress data according to any of a variety of compression standards or formats (e.g., GZIP, LZ4, SNAPPY, ZSTD, or the like). With some examples, interconnect link <NUM> can compress and decompress data using an instruction set configured for compression techniques (e.g., advanced vector extensions, or the like).

A more detailed description of how the present disclosure provides remote memory access via interconnect <NUM> is described below. However, in general interconnect link <NUM> provide for batch and/or compression based communication via interconnect <NUM> based on the communication pattern or behavior of interconnect <NUM>. Thus, it could be said that interconnect link <NUM> provides an adaptive compression based communication scheme for interconnect <NUM>.

During operation, data <NUM> stored in memory <NUM> of one compute socket can be remotely accessed by another compute socket. For example, processor <NUM> of compute socket <NUM> can access data <NUM> stored in memory <NUM> of compute socket <NUM>. Specifically, interconnect link <NUM> in compute socket <NUM> can request data <NUM> from interconnect link <NUM> of compute socket <NUM>. Interconnect link <NUM> of compute socket <NUM> and interconnect link <NUM> of compute socket <NUM> can communicate the data via interconnect <NUM> using the adaptive compression techniques described herein. Processor <NUM> of compute socket <NUM> when accessing the data <NUM> of memory <NUM> in compute socket <NUM> remotely may store the data <NUM> to memory <NUM> (shown) or to a memory location not shown (e.g., cache of processor <NUM>, or the like).

<FIG> is an example block diagram of a system <NUM> that may incorporate embodiments of the present disclosure. In general, <FIG> is illustrative of a computing platform like system <NUM>. However, system <NUM> includes four separate sockets arranged in a <NUM> architecture.

System <NUM> includes a four processors <NUM> each including a number of interconnect links <NUM>. Interconnect links <NUM> provide for communicative coupling of individuals ones of processors <NUM> to other ones of processors <NUM> via interconnects <NUM>. Processors <NUM> can be like processor <NUM> described above. Likewise, interconnect links <NUM> can be like interconnect link <NUM> and interconnects <NUM> can be like interconnect <NUM> described above.

It is noted that <FIG> depicts system <NUM> showing the NUMA architecture in a ring configuration. However, the present disclosure could be implemented by processors (e.g., processor <NUM>, processors <NUM>, or the like) arranged in a crossbar configuration, an <NUM> configuration, or the like. Examples are not limited in this context. More specifically, each processor <NUM> of system <NUM> includes two (<NUM>) interconnect links <NUM>. However, processors could be provided with three (<NUM>) or more interconnect links <NUM> to facilitate more advanced or complex NUMA architecture configurations (e.g., crossbar, or the like). Examples are not limited in this context.

<FIG> illustrates a routine <NUM> that can be implemented by interconnect circuitry (e.g., interconnect link <NUM>, interconnect links <NUM>, or the like). In general, interconnect circuitry can implement routine <NUM> to provide an adaptive compression scheme for communication of data over an interconnect bus (e.g., interconnect <NUM>, interconnects <NUM>, or the like). In particular, interconnect circuitry (e.g., interconnect link <NUM>, interconnect links <NUM>, or the like) sending data over the interconnect bus (e.g., interconnect <NUM>, interconnects <NUM>, or the like) can implement routine <NUM>. Although routine <NUM> can be implemented by any number of platform systems (e.g., system <NUM>, system <NUM>, or the like), routine <NUM> is described with reference to system <NUM> for convenience. Examples are not limited in this respect.

Further, for purposes of clarity, the compute socket sending data is referred to as the home socket or the remote socket while the compute socket receiving the data is referred to as the requesting socket.

Routine <NUM> can begin at block <NUM> "receive, at an interconnect link, data for transmission over an interconnect bus" where data for transmission over an interconnect bus (to a requesting socket) can be received at interconnect link (at the remote socket). For example, interconnect link <NUM> can receive data <NUM> for transmission over interconnect <NUM>. As a specific example, interconnect link <NUM> of processor <NUM> of compute socket <NUM> can receive data <NUM> from memory <NUM> for transmission to interconnect link <NUM> of processor <NUM> of compute socket <NUM> via interconnect <NUM>.

At decision block <NUM> "is batch processing (BP) flag set?" it is determined whether a batch processing flag is set. For example, an interconnect link <NUM> of the remote socket can determine whether a batch processing flag is set. In some examples, the batch processing flag can be a hardware register setting, a software register setting, or another type of flag usable in computing applications. From decision block <NUM>, routine <NUM> can proceed to either decision block <NUM> or decision block <NUM>. In particular, routine <NUM> can proceed from decision block <NUM> to decision block <NUM> based on a determination that the batch processing flag is not set while routine <NUM> can proceed from decision block <NUM> to decision block <NUM> based on a determination that the batch processing flag is set.

At decision block <NUM> "bandwidth utilization percentage (%) greater than or equal (≥) to a first threshold value?" it is determined whether the bandwidth utilization (e.g., in percent, or the like) of the interconnect bus is greater than or equal to a first threshold value. For example, interconnect link <NUM> can determine whether the bandwidth utilization of interconnect <NUM> is greater than or equal to (or merely greater than, or the like) a first threshold utilization value. In some examples, the first threshold utilization value can be <NUM>% utilization, <NUM>% utilization, or <NUM>% utilization.

From decision block <NUM>, routine <NUM> can proceed to either decision block <NUM> or block <NUM>. In particular, routine <NUM> can proceed from decision block <NUM> to decision block <NUM> based on a determination the bandwidth utilization of the interconnect bus is greater than or equal to the first threshold value while routine <NUM> can proceed from decision block <NUM> to block <NUM> based on a determination that the bandwidth utilization of the interconnect bus is not greater than or equal to the first threshold value.

With some examples, interconnect link <NUM> can determine a utilization of interconnect <NUM> based on a number of runtime monitoring techniques, such as, for example, profiler circuitry or profiler software. As a specific example, interconnect link <NUM> can implement profiling like VTune, Oprofile, Perf Collect, or the like.

At decision block <NUM> "bandwidth utilization percentage (%) greater than or equal (≥) to a second threshold value?" it is determined whether the bandwidth utilization (e.g., in percent, or the like) of the interconnect bus is greater than or equal to a second threshold value. For example, interconnect link <NUM> can determine whether the bandwidth utilization of interconnect <NUM> is greater than or equal to (or merely greater than, or the like) a second threshold utilization value. In some examples, the second threshold value will be higher than the first threshold value. For example, the second threshold value can be <NUM>%, <NUM>%, <NUM>%, <NUM>%, <NUM>%, <NUM>%, <NUM>%, or the like.

From decision block <NUM>, routine <NUM> can proceed to either decision block <NUM> or block <NUM>. In particular, routine <NUM> can proceed from decision block <NUM> to decision block <NUM> based on a determination the bandwidth utilization of the interconnect bus is greater than or equal to the second threshold value while routine <NUM> can proceed from decision block <NUM> to block <NUM> based on a determination that the bandwidth utilization of the interconnect bus is not greater than or equal to the second threshold value.

At decision block <NUM> "batch process?" it is determined whether to batch process the data. For example, interconnect link <NUM> can determine whether batch processing of data communicated over interconnect <NUM> is allowed and/or desired. In some examples, whether to batch process can be determined based of a register value. With other examples, whether to batch process can be determined based of a third (higher than the second) threshold value. As a specific example, interconnect link <NUM> can determine to batch process if the utilization of interconnect <NUM> is a threshold value (e.g., <NUM>%, <NUM>%, or the like) higher than the second threshold value. In some examples, the threshold values, the compression scheme, whether to batch process, or the like can be specified in a five (<NUM>) layer model (e.g., physical layer, link layer, routing layer, transport layer, protocol layer, or the like).

From decision block <NUM>, routine <NUM> can proceed to either block <NUM> or block <NUM>. In particular, routine <NUM> can proceed from decision block <NUM> to block <NUM> based on a determination to batch process the data while routine <NUM> can proceed from decision block <NUM> to block <NUM> based on a determination to not batch process the data.

At block <NUM> "set batch processing (BP) flag" the batch processing flag can be set. For example, interconnect link <NUM> can set the batch processing flag. At block <NUM> "wait for more data (return to block <NUM>)" routine <NUM> can wait for more data and return to block <NUM> responsive to receiving more data to transmit via interconnect <NUM>.

At decision block <NUM> "data ≥ packet size" it is determined whether the amount or quantity (e.g., bits, bytes, packets, or the like) of received data is greater than or equal (≥) to a batch processing packet size. In general, the batch processing packet size can be any number of data packets. However, generally, the number of packets for batch processing can be determined based on maximizing the compression ratio and/or minimizing the packet header overhead. With some examples, the number of packet for batch processing can be specified in a <NUM> layer model and may be determined in advance (e.g., via sensitivity experiments, or the like).

From decision block <NUM>, routine <NUM> can proceed to either block <NUM> or block <NUM>. In particular, routine <NUM> can proceed from decision block <NUM> to block <NUM> based on that the data received is not greater than or equal to the packet size while routine <NUM> can proceed from decision block <NUM> to block <NUM> based on a determination that the data to data received is greater than or equal to the packet size.

At block <NUM> "set compression flag and compress data" the data is compressed and a compression flag is set. For example, interconnect link <NUM> can compress data <NUM> received and can set a compression flag (e.g., hardware register, software flag, indication in the <NUM> layer model, or the like). With some examples, where batch processing is occurring, the received data can be combined (e.g., bitwise and, or the like) prior to compressing. Further, at block <NUM> interconnect link <NUM> can compress the data <NUM> (or the batch of data <NUM>).

At block <NUM> "add delay" a delay can be added before proceeding to transmit the data at block <NUM>. For example, interconnect link <NUM> can delay prior to transmitting data <NUM> via interconnect <NUM>. With some examples the delay can be randomly selected from a range of values. For example, the delay can be between <NUM> and <NUM> nanoseconds. With some examples, interconnect link <NUM> can add a delay based on the utilization percentage of interconnect <NUM>. As a specific example, the delay may be a function of the bandwidth utilization of interconnect <NUM> and a random seed.

At block <NUM> "transmit the data and reset the batch processing (BP) flag" the interconnect link can transmit the data via the interconnect bus and can reset the batch processing flag. For example, interconnect link <NUM> can transmit data <NUM> (e.g., compressed, uncompressed, or the like) via interconnect <NUM> and can reset the batch processing flag. In particular, interconnect link <NUM> from one compute socket can transmit the data to another interconnect link <NUM> of another compute socket.

<FIG> illustrates a routine <NUM> that can be implemented by interconnect circuitry (e.g., interconnect link <NUM>, interconnect links <NUM>, or the like). In general, interconnect circuitry can implement routine <NUM> to provide an adaptive decompression scheme for communication of data over an interconnect bus (e.g., interconnect <NUM>, interconnects <NUM>, or the like). In particular, interconnect circuitry (e.g., interconnect link <NUM>, interconnect links <NUM>, or the like) receiving data over the interconnect bus (e.g., interconnect <NUM>, interconnects <NUM>, or the like) can implement routine <NUM>. Although routine <NUM> can be implemented by any number of platform systems (e.g., system <NUM>, system <NUM>, or the like), routine <NUM> is described with reference to system <NUM> for convenience. Examples are not limited in this respect.

Routine <NUM> can begin at block <NUM> "receive, at an interconnect link, data via an interconnect bus" where data can be received (e.g., from a remote socket) at an at interconnect link (at a requesting socket) via an interconnect bus. For example, interconnect link <NUM> can receive data <NUM> transmitted via interconnect <NUM>. As a specific example, interconnect link <NUM> of processor <NUM> of compute socket <NUM> can receive data <NUM> transmitted by interconnect link <NUM> of processor <NUM> of compute socket <NUM> via interconnect <NUM>.

At decision block <NUM> "is compression flag set?" it is determined whether a compression flag is set. For example, an interconnect link <NUM> of the requesting socket can determine whether a compression flag is set. In some examples, the compression flag can be a hardware register setting, a software register setting, a setting in the <NUM>-layer model, or another type of flag usable in computing applications. From decision block <NUM>, routine <NUM> can proceed to either block <NUM> or block <NUM>. In particular, routine <NUM> can proceed from decision block <NUM> to block <NUM> based on a determination that the compression flag is set while routine <NUM> can proceed from decision block <NUM> to block <NUM> based on a determination that the compression flag is not set.

At block <NUM> "decompress data" the interconnect link can decompress the received data. For example interconnect link <NUM> can decompress the data received via interconnect <NUM>. At block <NUM> "deliver data" the interconnect link can deliver the data. For example, interconnect link <NUM> can save the data to memory <NUM> of the requesting socket. As another example, interconnect link <NUM> can deliver the data to a cache of processor <NUM>. As another example, interconnect link <NUM> can provide the data directly to a core of processor <NUM>.

<FIG> illustrate a technique <NUM> that can be implemented at a requesting compute socket to provide remote access to data at a remote compute socket. For example, compute socket <NUM>, as a requesting socket, could implement technique <NUM>. It is noted that technique <NUM> can be implemented by any number of platform systems (e.g., system <NUM>, system <NUM>, or the like), however, technique <NUM> is described with reference to system <NUM> for convenience. Examples are not limited in this respect. These figures show processor <NUM>, and components of processor <NUM> (e.g., interconnect link <NUM>, memory controller <NUM>, processor cores, processor cache, and the like). It is noted that technique <NUM> could be implemented by another processor or system-on-chip (SoC) different than that depicted (e.g., a processor <NUM> having a HyperTransport® link, a QPI link, a UPI link, or the like).

In general, technique <NUM> details sending a request for remote data from a requesting socket to a remote socket. As shown in <FIG>, technique <NUM> can include block <NUM>. At block <NUM> a core <NUM> of processor <NUM> can request data <NUM> from cache <NUM>. Cache <NUM> can determine (e.g., based on a NUMA architecture, or the like) that data <NUM> is remotely located (e.g., located in a different compute socket, or the like). Responsive to the determination that the data <NUM> requested by core <NUM> is remote, cache <NUM> can forward the request to interconnect link <NUM>. For example, at show in block <NUM> of <FIG>, interconnect link <NUM> can receive a request for access to data <NUM>.

<FIG> illustrates technique <NUM> and block <NUM> where interconnect link <NUM> transmits the request to an interconnect link of a remote socket via interconnect <NUM>.

<FIG> illustrate a technique <NUM> that can be implemented at a remote compute socket to provide remote access to data for a requesting compute socket. For example, compute socket <NUM>, as a remote socket, could implement technique <NUM>. It is noted that technique <NUM> can be implemented by any number of platform systems (e.g., system <NUM>, system <NUM>, or the like), however, technique <NUM> is described with reference to system <NUM> for convenience. Examples are not limited in this respect. These figures show processor <NUM>, and components of processor <NUM> (e.g., interconnect link <NUM>, memory controller <NUM>, processor cores, processor cache, and the like). It is noted that technique <NUM> could be implemented by another processor or system-on-chip (SoC) different than that depicted (e.g., a processor <NUM> having a HyperTransport® link, a QPI link, a UPI link, or the like).

As shown in <FIG>, technique <NUM> can include block <NUM>. At block <NUM> interconnect link <NUM> of processor <NUM> can receive a remote data access request from a requesting socket. As shown in <FIG> and block <NUM>, interconnect link <NUM> can demand data <NUM> from cache <NUM> of processor <NUM>. As indicated by <FIG>, interconnect link <NUM> can prefetch data <NUM> from memory <NUM> (now shown) via memory controller <NUM> at block <NUM>.

<FIG> illustrates technique <NUM> and block <NUM> where interconnect link <NUM> can receive the demanded data <NUM>. In some examples, data <NUM> can be returned to interconnect link <NUM> via memory controller <NUM> and cache <NUM>. Turning to <FIG>, at block <NUM> of technique <NUM>, interconnect link <NUM> can compress data <NUM>. In particular, at block <NUM>, interconnect link <NUM> can implement routine <NUM> to determine whether to add a delay before transmission of data <NUM>, compress data <NUM>, or packetize and compress data <NUM>. With some examples, compression of data <NUM> can be facilitated by circuitry of interconnect link <NUM> and cache <NUM>.

<FIG> shows block <NUM> of technique <NUM> where interconnect link <NUM> transmits the data <NUM> (e.g., uncompressed, compressed, or packetized and compressed) to the requesting socket.

In general, technique <NUM> details receiving remote data from a remote socket. As shown in <FIG>, technique <NUM> can include block <NUM>. At block <NUM> an interconnect link <NUM> of processor <NUM> can receive data <NUM> via interconnect <NUM>. For example, interconnect link <NUM> can receive, via interconnect <NUM>, data <NUM> requested by core <NUM> at block <NUM> detailed in <FIG>.

As shown in <FIG>, technique <NUM> can include block <NUM> where interconnect link <NUM> can provide the data <NUM> directly to the requesting core <NUM>. In some examples, such as, where data <NUM> is compressed, interconnect link <NUM> can also decompress the data.

<FIG> illustrates computer-readable storage medium <NUM>. Computer-readable storage medium <NUM> may comprise any non-transitory computer-readable storage medium or machine-readable storage medium, such as an optical, magnetic or semiconductor storage medium. In various embodiments, computer-readable storage medium <NUM> may comprise an article of manufacture. In some embodiments, <NUM> may store computer executable instructions <NUM> with which circuitry (e.g., processor <NUM>, or the like) can execute. For example, computer executable instructions <NUM> can include instructions to implement operations described with respect to routine <NUM>, routine <NUM>, technique <NUM>, technique <NUM>, and/or technique <NUM>. Examples of computer-readable storage medium <NUM> or machine-readable storage medium may include any tangible media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of computer executable instructions <NUM> may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like.

<FIG> illustrates a diagrammatic representation of a machine <NUM> in the form of a computer system within which a set of instructions may be executed for causing the machine to perform any one or more of the methodologies discussed herein. More specifically, <FIG> shows a diagrammatic representation of the machine <NUM> in the example form of a computer system, within which computer executable instructions <NUM> (e.g., software, a program, an application, an applet, an app, or other executable code) for causing the machine <NUM> to perform any one or more of the methodologies discussed herein may be executed. For example the computer executable instructions <NUM> may cause the machine <NUM> to execute routine <NUM> of <FIG>, routine <NUM> of <FIG>, technique <NUM> of <FIG>, technique <NUM> of <FIG>, or technique <NUM> of <FIG>, or the like. More generally, the computer executable instructions <NUM> may cause the machine <NUM> to provide remote access to data of compute sockets as detailed herein.

The computer executable instructions <NUM> transform the general, non-programmed machine <NUM> into a particular machine <NUM> programmed to carry out the described and illustrated functions in a specific manner. In alternative embodiments, the machine <NUM> operates as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine <NUM> may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine <NUM> may comprise, but not be limited to, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a PDA, an entertainment media system, a cellular telephone, a smart phone, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, a web appliance, a network router, a network switch, a network bridge, or any machine capable of executing the computer executable instructions <NUM>, sequentially or otherwise, that specify actions to be taken by the machine <NUM>. Further, while only a single machine <NUM> is illustrated, the term "machine" shall also be taken to include a collection of machines <NUM> that individually or jointly execute the computer executable instructions <NUM> to perform any one or more of the methodologies discussed herein.

The machine <NUM> may include processors <NUM>, memory <NUM>, and I/O components <NUM>, which may be configured to communicate with each other such as via a bus <NUM>. In an example embodiment, the processors <NUM> (e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an ASIC, a RadioFrequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a first processor <NUM> and a second processor <NUM> each including interconnect link <NUM>. The first processor <NUM> and the second processor <NUM> may be coupled via interconnect <NUM>.

The memory <NUM> may include a main memory <NUM>, a static memory <NUM>, and a storage unit <NUM>, both accessible to the processors <NUM> such as via the bus <NUM>. The main memory <NUM>, the static memory <NUM>, and storage unit <NUM> store the computer executable instructions <NUM> embodying any one or more of the methodologies or functions described herein. The computer executable instructions <NUM> may also reside, completely or partially, within the main memory <NUM>, within the static memory <NUM>, within machine-readable medium <NUM> within the storage unit <NUM>, within at least one of the processors <NUM> (e.g., within the processor's cache memory), or any suitable combination thereof, during execution thereof by the machine <NUM>.

The I/O components <NUM> may include a wide variety of components to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I/O components <NUM> that are included in a particular machine will depend on the type of machine. For example, portable machines such as mobile phones will likely include a touch input device or other such input mechanisms, while a headless server machine will likely not include such a touch input device. It will be appreciated that the I/O components <NUM> may include many other components that are not shown in <FIG>. The I/O components <NUM> are grouped according to functionality merely for simplifying the following discussion and the grouping is in no way limiting. In various example embodiments, the I/O components <NUM> may include output components <NUM> and input components <NUM>. The output components <NUM> may include visual components (e.g., a display such as a plasma display panel (PDP), a light emitting diode (LED) display, a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)), acoustic components (e.g., speakers), haptic components (e.g., a vibratory motor, resistance mechanisms), other signal generators, and so forth. The input components <NUM> may include alphanumeric input components (e.g., a keyboard, a touch screen configured to receive alphanumeric input, a photo-optical keyboard, or other alphanumeric input components), point-based input components (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or another pointing instrument), tactile input components (e.g., a physical button, a touch screen that provides location and/or force of touches or touch gestures, or other tactile input components), audio input components (e.g., a microphone), and the like.

In further example embodiments, the I/O components <NUM> may include biometric components <NUM>, motion components <NUM>, environmental components <NUM>, or position components <NUM>, among a wide array of other components. For example, the biometric components <NUM> may include components to detect expressions (e.g., hand expressions, facial expressions, vocal expressions, body gestures, or eye tracking), measure biosignals (e.g., blood pressure, heart rate, body temperature, perspiration, or brain waves), identify a person (e.g., voice identification, retinal identification, facial identification, fingerprint identification, or electroencephalogram-based identification), and the like. The motion components <NUM> may include acceleration sensor components (e.g., accelerometer), gravitation sensor components, rotation sensor components (e.g., gyroscope), and so forth. The environmental components <NUM> may include, for example, illumination sensor components (e.g., photometer), temperature sensor components (e.g., one or more thermometers that detect ambient temperature), humidity sensor components, pressure sensor components (e.g., barometer), acoustic sensor components (e.g., one or more microphones that detect background noise), proximity sensor components (e.g., infrared sensors that detect nearby objects), gas sensors (e.g., gas detection sensors to detection concentrations of hazardous gases for safety or to measure pollutants in the atmosphere), or other components that may provide indications, measurements, or signals corresponding to a surrounding physical environment. The position components <NUM> may include location sensor components (e.g., a GPS receiver component), altitude sensor components (e.g., altimeters or barometers that detect air pressure from which altitude may be derived), orientation sensor components (e.g., magnetometers), and the like.

Communication may be implemented using a wide variety of technologies. The I/O components <NUM> may include communication components <NUM> operable to couple the machine <NUM> to a network <NUM> or devices <NUM> via a coupling <NUM> and a coupling <NUM>, respectively. For example, the communication components <NUM> may include a network interface component or another suitable device to interface with the network <NUM>. In further examples, the communication components <NUM> may include wired communication components, wireless communication components, cellular communication components, Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components to provide communication via other modalities. The devices <NUM> may be another machine or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a USB).

The various memories (i.e., memory <NUM>, main memory <NUM>, static memory <NUM>, and/or memory of the processors <NUM>) and/or storage unit <NUM> may store one or more sets of instructions and data structures (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. These instructions (e.g., the computer executable instructions <NUM>), when executed by processors <NUM>, cause various operations to implement the disclosed embodiments.

As used herein, the terms "machine-storage medium," "device-storage medium," "computer-storage medium" mean the same thing and may be used interchangeably in this disclosure. The terms refer to a single or multiple storage devices and/or media (e.g., a centralized or distributed database, and/or associated caches and servers) that store executable instructions and/or data. The terms shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media, including memory internal or external to processors. Specific examples of machine-storage media, computer-storage media and/or device-storage media include non-volatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), FPGA, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The terms "machine-storage media," "computer-storage media," and "device-storage media" specifically exclude carrier waves, modulated data signals, and other such media, at least some of which are covered under the term "signal medium" discussed below.

In various example embodiments, one or more portions of the network <NUM> may be an ad hoc network, an intranet, an extranet, a VPN, a LAN, a WLAN, a WAN, a WWAN, a MAN, the Internet, a portion of the Internet, a portion of the PSTN, a plain old telephone service (POTS) network, a cellular telephone network, a wireless network, a Wi-Fi® network, another type of network, or a combination of two or more such networks. For example, the network <NUM> or a portion of the network <NUM> may include a wireless or cellular network, and the coupling <NUM> may be a Code Division Multiple Access (CDMA) connection, a Global System for Mobile communications (GSM) connection, or another type of cellular or wireless coupling. In this example, the coupling <NUM> may implement any of a variety of types of data transfer technology, such as Single Carrier Radio Transmission Technology (1xRTT), Evolution-Data Optimized (EVDO) technology, General Packet Radio Service (GPRS) technology, Enhanced Data rates for GSM Evolution (EDGE) technology, third Generation Partnership Project (3GPP) including <NUM>, fourth generation wireless (<NUM>) networks, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) standard, others defined by various standard-setting organizations, other long range protocols, or other data transfer technology.

The computer executable instructions <NUM> may be transmitted or received over the network <NUM> using a transmission medium via a network interface device (e.g., a network interface component included in the communication components <NUM>) and utilizing any one of a number of well-known transfer protocols (e.g., hypertext transfer protocol (HTTP)). Similarly, the computer executable instructions <NUM> may be transmitted or received using a transmission medium via the coupling <NUM> (e.g., a peer-to-peer coupling) to the devices <NUM>. The terms "transmission medium" and "signal medium" mean the same thing and may be used interchangeably in this disclosure. The terms "transmission medium" and "signal medium" shall be taken to include any intangible medium that is capable of storing, encoding, or carrying the computer executable instructions <NUM> for execution by the machine <NUM>, and includes digital or analog communications signals or other intangible media to facilitate communication of such software. Hence, the terms "transmission medium" and "signal medium" shall be taken to include any form of modulated data signal, carrier wave, and so forth. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a matter as to encode information in the signal.

Terms used herein should be accorded their ordinary meaning in the relevant arts, or the meaning indicated by their use in context, but if an express definition is provided, that meaning controls.

Claim 1:
A computer-implemented method, comprising:
receiving (<NUM>), at an interconnect link, data to be transmitted via an interconnect bus coupled to the interconnect link;
determining (<NUM>) whether a bandwidth utilization of the interconnect bus is greater than or equal to a first threshold value;
determining (<NUM>) whether the bandwidth utilization of the interconnect bus is greater than or equal to a second threshold value, the second threshold value greater than the first threshold value; and
transmitting (<NUM>) the data to a requesting interconnect link via the interconnect bus based on determination that the bandwidth utilization of the interconnect bus is not greater than or equal to the first threshold value;
adding (<NUM>) a delay before transmitting the data and transmitting (<NUM>), after the delay, the data to a requesting interconnect link via the interconnect bus based on determination that the bandwidth utilization of the interconnect bus is greater than or equal to the first threshold value and a determination that the bandwidth utilization of the interconnect bus is not greater than or equal to the second threshold value; or
compressing (<NUM>) the data and transmitting (<NUM>) the compressed data to a requesting interconnect link via the interconnect bus based on determination that the bandwidth utilization of the interconnect bus is greater than or equal to the second threshold value.