Hewlett Packard Enterprise Development LP

Hewlett-packard Development Company, L.p.

Compaq Computer Corporation, Inc.

Other

Tandem Computers Incorporated

Compaq Computer Company

Charles Stuart Johnson

Harumi Kuno

David Hege

Gary Stephen Smith

Robert Lennie

Ronald M Cassou

James Hyungsun Park

Trina R Wisler

David J Wisler

Tuan Tran

Onkar Patil

Mesut Kuscu

Goetz Graefe

Paolo Faraboschi

Robert S Schreiber

Mark David Lillibridge

Andrew Christopher Walton

Sitaram V Lanka

Joseph Andrew Tucek

William J Carley

Albert C Gondi

Malcolm Mosher, Jr

Haris Volos

Qiong Cai

Charles B Morrey, Iii

Muhammad Shafiq

Milind M Chabbi

Al Davis

Shang-Sheng Tung

Larry W Emlich

Yu-Cheung Cheung

Alexander V Jizrawi

Jim B Tate

Sang-Sheng Tung

Wey Guy

Paul Komosinski

Muhammad Shariq

Y C Cheung

Shang-Shen Tung

William Scherer

In one example, a central processing unit (CPU) with dynamic thread mapping includes a set of multiple cores each with a set of multiple threads. A set of registers for each of the multiple threads monitors for in-flight memory requests the number of loads from and stores to at least a first memory interface and a second memory interface by each respective thread. The second memory interface has a greater latency than the first memory interface. The CPU further has logic to map and migrate each thread to respective CPU cores where the number of cores accessing only one of the at least first and second memory interfaces is maximized.

Dynamic thread mapping

Simulator based detection of a violation of a coherency protocol in an incoherent shared memory system is disclosed. One example is a system including a simulator running on a first computing system, where the simulator simulates a second computing system that is a target for an application to be tested, and where the simulator includes a cache manager to monitor a state of a plurality of simulated caches in an incoherent memory system shared by a plurality of simulated processors, wherein the plurality of simulated processors simulate operations of a respective plurality of processors of the second computing system, and detect a violation of a coherency protocol in the shared memory system, and an alert generator to provide, via a computing device on the first computing system, an alert indicative of the violation.

Simulator based detection of a violation of a coherency protocol in an incoherent shared memory system

In some examples, a node of a computing system may include a failure identification engine and a failure response engine. The failure identification engine may identify a failure condition for a system function of the node and the failure response engine may store a failure indication in a shared memory to trigger takeover of the system function by a different node of the computing system.

Failure indication in shared memory

A high performance computing system that includes a shared fabric memory and a plurality of processors is disclosed. A first processor is coupled to a local storage and executes a first process that, in combination with other processes, causes the plurality of processors to perform certain actions including transferring, from the shared fabric memory to the local storage, a first value corresponding to a first cell of a first set of cells and a first sweep of a stencil code. The actions further include transferring, from a first logical partition in the shared fabric memory associated with the first cell to the local storage, a second value corresponding to a second cell related to the first cell and not in the first set of cells. Further, these actions include updating, by the first process, the first value based on at least the first value and the second value.

Data update of shared fabric memory in a high performance computing system

A high performance computing system including processing circuitry and a shared fabric memory is disclosed. The processing circuitry includes processors coupled to local storages. The shared fabric memory includes memory devices and is coupled to the processing circuitry. The shared fabric memory executes a first sweep of a stencil code by sequentially retrieving data stripes. Further, for each retrieved data stripe, a set of values of the retrieved data stripe are updated substantially simultaneously. For each retrieved data stripe, the updated set of values are stored in a free memory gap adjacent to the retrieved data stripe. For each retrieved data stripe, the free memory gap is advanced to an adjacent memory location. A sweep status indicator is incremented from the first sweep to a second sweep.

Sequential memory access on a high performance computing system

Systems and methods associated with page modification are disclosed. One example method may be embodied on a non-transitory computer-readable medium storing computer-executable instructions. The instructions, when executed by a computer, may cause the computer to fetch a page to a buffer pool in a memory. The page may be fetched from at least one of a log and a backup using single page recovery. The instructions may also cause the computer to store a modification of the page to the log. The modification may be stored to the log as a log entry. The instructions may also cause the computer to evict the page from memory when the page is replaced in the buffer pool. Page writes associated with the eviction may be elided.

Eliding memory page writes upon eviction after page modification

A technique includes using a primary commit coordinator in a distributed file system as a participant in at least one transaction associated with a file operation to commit the transaction(s) to an associated storage segment of the file system. The primary commit coordinator is used to communicate with at least one other participant in the transaction(s) using a three phase commit protocol to generate transaction states associated with committing the transaction(s). The technique includes selectively checkpointing the transaction states to a backup commit coordinator that is associated with the primary commit coordinator to allow the backup commit coordinator to takeover committing the transaction.

Three phase commit for a distributed file system

Systems and methods associated with computing cluster synchronization are disclosed. One example method includes periodically requesting timing values from a set of notes in a computing cluster. The method also includes receiving timing values from members of the set of nodes. The method also includes providing a synchronization value to members of the set of nodes. The synchronization value may be generated based on the timing values. Additionally, the synchronization value may be used to order events across the members.

Node cluster synchronization

Examples include a system comprising a non-volatile memory, a cluster management interface, and a multi-node cluster. In some examples, the cluster management interface may monitor a system critical alert to determine if the system critical alert has been triggered. Based on the determination that it has been triggered, the cluster management interface may multicast a system failure notification. The multi-node cluster of the system has multiple nodes, each node connected to the non-volatile memory and having a processor and a processor cache. Each node of the multi-node cluster may determine if the system failure notification has been received and based on the determination that it has been received, each node may freeze execution of all processes on the process and flush the processor cache to the non-volatile memory.

Failure notifications in multi-node clusters

A method of processing a transaction includes processing a transaction workload in a primary process pair on a first node in a cluster of nodes, the processing using at least one stable storage volume for storing a database and another stable storage volume for storing a log, the at least one stable storage volume and the log storage volume forming a log storage group. The method further includes performing checkpointing operations via the network from the primary process pair to a backup process pair while processing the transaction workload, the backup process pair operating on a second node in the cluster of nodes. The method further includes detecting a failure making the first node inoperable or inaccessible, and after detecting the failure, engaging the backup process pair to take over the transaction processing workload of the primary process pair, the backup process pair being configured to operate with the log storage group used by the primary process pair on the failed node.

Transaction processing apparatus and method

A method of transferring a transaction workload of a primary process pair. The primary pair has access to a stable storage volume for storing data items and a log for storing transaction processing updates to data items. A backup process pair is established for the primary pair and information is transferred thereto so that it can take over for the primary pair should that pair fail. Additionally, a lock table is maintained and update records are written to the log by the primary pair. The update records include any locks from the lock table that related to the update records. When a failure of the primary pair occurs, the storage volume is locked, and the backup pair reads the log to reconstruct a lock table. Once the locks have been reconstructed, the lock on the storage volume is released and the backup pair operates to process the workload.

Minimum latency reinstatement of database transaction locks

A Registration protocol is used in transaction processing for normal operations. If an error occurs, the system reverts to a Full Broadcast protocol. The Registration Protocol reduces the number of messages that are sent among CPUs in a cluster thereby permitting performance improvements in the system. The Registration Protocol has Begin, DPCheck, PhaseFlush and Phase(lock release) phases just as does the Full Broadcast Protocol, thereby permitting the Full Broadcast protocol to step in at any phase after an error is detected.

Hybrid method for flushing transaction state in a fault-tolerant clustered database

A modified transaction registration protocol is disclosed. The registration protocol is inherently centralized in that processes requesting registration to participate in the work of a transaction, must send a request to a Broadcast Owner CPU which is the CPU that initiated the transaction. The processes wait, suspended, until a response is received from the Broadcast Owner CPU. However, if the Broadcast Owner CPU fails to respond to the registration request, then the processes that are waiting are incapable performing work for the transaction. While a CPU failure may not occur often, in a fault-tolerant system, such events must be accounted for. Therefore, the transaction registration protocol is modified to revert to a Full Broadcast transaction protocol and complete any outstanding registration requests. This is accomplished by distributing transactions to all of the CPUs in the system, and in each CPU forcing the completion of registration requests in each CPU.

Method for handling node failures and reloads in a fault tolerant clustered database supporting transaction registration and fault-in logic

A method and system for backing up primary nodes onto backup nodes where the primary nodes can each originate a distributed transaction and can participate in a distributed transaction. The backup nodes, after a primary node failure, undo all transactions whose state is unknown on the backup node and all committed transactions which, if kept, would lead to an inconsistent set of backup nodes. First, committed transactions are undone if commits for them were not received on all back up nodes to the primary nodes that participated in the transaction. Second, all committed transactions that potentially depend on the committed transactions that were undone are also undone. Only those transactions that are provably independent of the committed transactions that were undone are kept. The result is a set of back up nodes which can support operations until the failing primary node is restored.

System and method for replication of distributed databases that span multiple primary nodes

A monitor function is implemented to monitor and control service processes and other system entities that perform tasks on a distributed network. The monitor function tracks the demise and instantiation of processes and entities that either export or import instrumentation. Any service process or other system entity (driver, interrupt handler, system library procedure) can export instruments (indicators, controls, testpoints). Instrument updates are propagated automatically if they are significant. The importing process conveys the information to a management system so that a human operator, or automated system, can observe and control the operation of the network service. One aspect of the invention uses a backup exporter to take over the processing of an exporter that has become nonfunctional. Another aspect of the invention determines when a CPU has gone down and acts accordingly to identify service processes that were associated with an exporter in the down CPU. For each exporter in the down CPU, any importer that was monitoring with the exporter must perform a switchover to monitor instrumentation on the new exporter in a fault tolerant manner. Additional methods are disclosed which implement fault tolerant monitoring and control in a distributed network.

Enhanced instrumentation software in fault tolerant systems

Growing community of inventors

San Jose, CA, United States of America

Charles Stuart Johnson