Intel Corporation

Vmware, Inc.

Bitfusion.io, Inc.

Mazhar I Memon

Steven R King

Maciej Bajkowski

Subramanian Rama

Frank L Berry

Amit Kumar

Ram Huggahalli

Aidan Cully

Xia Zhu

Nitin Bhardwaj

Theodore Willke, Ii

Travis T Schluessler

Bryan E Veal

Steen K Larsen

Daniel S Lake

Zheng Li

Miha Cancula

Tiejun Chen

Shreekanta Das

Peter Buckingham

Chris Wolf

Vance Miller

Dušan Veljko

A method for executing an application over a plurality of nodes in each of which an application monitor and a runtime are executing includes executing a first portion of the application by first threads of the runtime of the first node and a second portion of the application by second threads of the runtime of the second node, and under control of the application monitors of the first and second nodes and while executing the first portions and second portions of the application, migrating workloads of one or more of the first threads from the first node to the second node for execution by the second threads.

Co-execution of an application among a plurality of compute nodes through application-level virtualization

At least one application of a client executes via system software on a hardware computing system that includes at least one CPU and at least one coprocessor. A virtualization layer establishes unified memory address space between the client and the hardware computing system, which also includes memory associated with the at least one coprocessor. The virtualization layer then synchronizes memory associated with the client and memory associated the at least one coprocessor. The virtualization layer may be installed and run in a non-privileged, user space, without modification of the application or of the system software running on the hardware computing system.

Unified host memory for coprocessors

An interface software layer is interposed between at least one application and a plurality of coprocessors. A data and command stream issued by the application(s) to an API of an intended one of the coprocessors is intercepted by the layer, which also acquires and stores the execution state information for the intended coprocessor at a coprocessor synchronization boundary. At least a portion of the intercepted data and command stream data is stored in a replay log associated with the intended coprocessor. The replay log associated with the intended coprocessor is then read out, along with the stored execution state information, and is submitted to and serviced by at least one different one of the coprocessors other than the intended coprocessor.

System and method for coordinating use of multiple coprocessors

Disclosed herein is the integration into edge nodes of a telecommunications network system of client computer system and server computer system where the server computer system includes a pool of shareable accelerators and the client computer runs an application program that is assisted by the pool of accelerators. The edge nodes connect to user equipment, and some of the user equipment can themselves act as one of the client computer systems. In some embodiments, the accelerators are GPUs, and in other embodiments, the accelerators are artificial intelligence accelerators.

Edge artificial intelligence (AI) computing in a telecommunications network

Execution of multiple execution streams is scheduled on at least one coprocessor. A software layer located logically between applications and the at least one coprocessor intercepts a first API call from an application and determines that a first execution stream is to be executed. Before scheduling the first execution stream, the software layer transmits a response to the application indicating that the at least one coprocessor is ready to execute another execution stream. The software layer intercepts a second API call from the application and determines that a second execution stream including one or more kernels is to be executed. The software layer determines that the one or more kernels does not have a dependency on the first execution stream. The software layer schedules the one or more kernels for execution prior to when the at least one coprocessor has completed execution of the first execution stream.

Intelligent scheduling of coprocessor execution

In a data processing system running at least one application on a hardware platform that includes at least one processor and a plurality of coprocessors, at least one kernel dispatched by an application is intercepted by an intermediate software layer running logically between the application and the system software. Compute functions are determined within kernel(s), and data dependencies are determined among the compute functions. The compute functions are dispatched to selected ones of the coprocessors based at least in part on the determined data dependencies and kernel results are returned to the application that dispatched the respective kernel.

Virtualization of multiple coprocessors

Instructions of at least one application are executed via system software, on a hardware computing system that includes at least one processor and a plurality of coprocessors. At least one application program interface (API) is associated with each coprocessor. A state virtualization layer is installed logically between the application and the system software. The state virtualization layer examines an execution stream directed by the at least one application to a first one of the plurality of coprocessors; extracts the state of the first coprocessor; pauses execution of the first coprocessor; and at runtime, dynamically resumes execution of the execution stream, with the extracted state of the first coprocessor, on a second one of the plurality of coprocessors.

Intelligent coprocessor state virtualization

At least one application runs on a hardware platform that includes a plurality of coprocessors, each of which has a respective internal memory space. An intermediate software layer (MVL) is transparent to the application and intercepts calls for coprocessor use. If the data corresponding to an application's call, or separate calls from different entities (including different applications) to the same coprocessor, to the API of a target coprocessor, cannot be stored within the available internal memory space of the target coprocessor, but comprises data subsets that individually can, the MVL intercepts the call response to the application/entities and indicates that the target coprocessor can handle the request. The MVL then transfers the data subsets to the target coprocessor as needed by the corresponding kernel(s) and swaps out each data subset to the internal memory of another coprocessor to make room for subsequently needed data subsets.

Virtualization of multiple coprocessor memory

Execution of multiple execution streams is scheduled on a plurality of coprocessors. A software layer located logically between applications and the coprocessors determines dependencies within the execution streams, each said dependency being a condition in one of the execution streams that must be satisfied in order for execution of at least one other of the execution streams to proceed on corresponding ones of the coprocessors. The dependencies are then represented in a data structure and an optimized execution schedule is determined for the execution streams according to the dependencies. Simultaneous execution of a plurality of the execution streams is then dynamically reordered according to the optimized execution schedule.

In an embodiment, a method includes identifying a core of a multicore processor to which an incoming packet that is received in a packet buffer is to be directed, and if the core is powered down, transmitting a first message to cause the core to be powered up prior to arrival of the incoming packet at a head of the packet buffer. Other embodiments are described and claimed.

Reducing network latency during low power operation

In an embodiment, an apparatus is provided that may include an integrated circuit including switch circuitry to determine, at least in part, an action to be executed3 involving a packet. This determination may be based, at least in part, upon flow information determined, at least in part, from the packet, and packet processing policy information. The circuitry may examine the policy information to determine whether a previously-established packet processing policy has been established that corresponds, at least in part, to the flow information. If the circuitry determines, at least in part, that the policy has not been established and the packet is a first packet in a flow corresponding at least in part to the flow information, the switch circuitry may request that at least one switch control program module establish, at least in part, a new packet processing policy corresponding, at least in part, to the flow information.

Growing community of inventors

Beaverton, OR, United States of America

Mazhar I Memon