An apparatus and method for scheduling threads on local and remote processing resources. For example, one embodiment of an apparatus comprises: a local graphics processor to execute threads of an application; graphics processor virtualization circuitry and/or logic to generate a virtualized representation of a local processor; a scheduler to identify a first subset of the threads for execution on a local graphics processor and a second subset of the threads for execution on a virtualized representation of a local processor; the scheduler to schedule the first subset of threads on the local graphics processor and the second subset of the threads by transmitting the threads or a representation thereof to Cloud-based processing resources associated with the virtualized representation of the local processor; and the local graphics processor to combine first results of executing the first subset of threads on the local graphics processor with second results of executing the second subset of threads on the Cloud-based processing resources to render an image frame.

Systems and methods are provided for management of processor thread used in support of workspaces operating on an IHS (Information Handling System), where the workspaces operate in isolation from the operating system of the IHS. A remote workspace orchestration service manages deployment of workspaces on the IHS. The workspaces are instantiated and operate according to a workspace definition provided by the workspace orchestration service. A remote access controller of the IHS determine one or more processor threads of the IHS used in support of the workspaces. The remote access controller monitors memory utilization by the processor threads used in support of the workspaces in order to detect memory thrashing resulting from the operation of a particular workspace. Based on the monitored memory utilization, the processor threads used in support of the workspaces are modified in order to reduce memory thrashing during the operation of the workspaces.

One embodiment provides a method, including: producing, for each of a plurality of containers, a resource profile for each thread in each of the plurality of containers; identifying, for each of the plurality of containers and from, at least in part, the resource profiles, container dependencies between threads on a single of the plurality of containers; determining service dependencies between threads across different of the plurality of containers; scheduling, based upon the container dependencies and the service dependencies, threads to cores, wherein the scheduling is based upon minimizing thread processing times; and publishing the container dependencies and the service dependencies on a registry of the node clusters.

Techniques for providing a framework for handling execution of HA flows in an active-active storage node configuration. The techniques include receiving notifications of functional statuses of processes and/or equipment associated with storage nodes in the active-active configuration, making determinations regarding how to address HA events occurring on the processes and/or equipment associated with the storage nodes based on the received notifications, and, in response to a request to execute an HA flow for a respective HA event, determining whether to refuse the request to execute the HA flow, service the request to execute the HA flow, abort one or more HA flows in execution, and/or postpone execution of the HA flow to a later time based on one or more dependencies defining conditions for the HA flow. In this way, mutual interference of HA flows or other process threads in the active-active configuration can be reduced or eliminated.

The present disclosure provides a generic multi-source heterogeneous large-scale data system, including a sync node config unit, an install & deployment unit, a block & pipelining unit, a unilateral sync unit, a bilateral sync unit and a correctness guarantee unit. The system operates on a middle layer which is above a node database layer and beneath an application logic layer. In a data synchronization process, a client end transmits captured local change information to a server end in accordance with a synchronization task plan; the server end receives and transfers the change information to an asynchronous parallel message processing mechanism to be stored in a corresponding message queue; the server end polls a local message queue for reading to-be-processed change information, and then performs subsequent data change in accordance with rules for heterogeneous data mapping, so as to maintain consistence of synchronized data objects between a source end and a target end. The system of the present disclosure operates independently in a manner parallel to local applications of a synchronous node, and provides a guarantee mechanism of relaxed transaction for Internet distributed multi-source heterogeneous data synchronization through collaboration of loose coupling.

An agent application manages a response time relating to a communication between a manager and the agent application. The agent application executes processing according to a request from the manager by using a plurality of threads, a number of the plurality of threads being a threshold value or less, transmits, to the manager, data indicating a result of the processing executed by the agent application, and performs an adjustment to decrease the threshold value based on a change in response time in a plurality of response times corresponding to a plurality of instances of communications performed between the agent application and the manager.

Disclosed are computer-implemented methods, non-transitory computer-readable media, and systems for processing blockchain transactions. An example of a computer-implemented system includes a storage subsystem including one or more storage devices that store blockchain data, and one or more processors configured to support a first thread pool and a second thread pool. The second thread pool is dedicated to the storage subsystem. The system receives M blockchain transactions and executes N blockchain transactions out of the M blockchain transactions in parallel using K threads of the first thread pool. For blockchain transactions distributed to each one of the K threads, one or more coroutines are used for each blockchain transaction so that the blockchain transactions are executed asynchronously using the coroutines. A blockchain block is generated to include the M blockchain transactions and added to a blockchain stored in the storage subsystem.

A computing system includes processor cores for executing applications that utilize functionality provided by a deep neural network (“DNN”) processor. One of the cores operates as a resource and power management (“RPM”) processor core. When the RPM processor receives a request to execute a DNN workload, it divides the DNN workload into workload fragments. The RPM processor then determines whether a workload fragment is to be statically allocated or dynamically allocated to a DNN processor. Once the RPM processor has selected a DNN processor, the RPM enqueues the workload fragment on a queue maintained by the selected DNN processor. The DNN processor dequeues workload fragments from its queue for execution. Once execution of a workload fragment has completed, the DNN processor generates an interrupt indicating that execution of the workload fragment has completed. The RPM processor can then notify the processor core that originally requested execution of the workload fragment.

Allocating CPU cores to a thread running in a system that supports multiple concurrent threads includes training a first model to optimize core allocations to threads using training data that includes performance data, initially allocating cores to threads based on the first model, and adjusting core allocations to threads based on a second model that uses run time data and run time performance measurements. The system may be a storage system. The training data may include I/O workload data obtained at customer sites. The I/O workload data may include data about I/O rates, thread execution times, system response times, and Logical Block Addresses. The training data may include data from a site that is expected to run the second model. The first model may categorize storage system workloads and determine core allocations for different categories of workloads. Initially allocating cores to threads may include using information from the first model.

A method, computer program product, and computing system for monitoring utilization of each central processing unit (CPU) core of a plurality of CPU cores. An average input/output (IO) latency for an operating system thread executing on the CPU core of the plurality of CPU cores may be determined. The operating system thread IO polling cadence for the at least one operating system thread executing on at least one CPU core may be adjusted based upon, at least in part, the utilization of each CPU core of the plurality of CPU cores and the average IO latency for the operating system thread executing on each CPU core of the plurality of CPU cores.