G06F9/528

Filesystem using hardware transactional memory on non-volatile dual in-line memory module

A computer-implemented method comprises receiving a request to write to a file and, in response to the request, determining that the file exists in a storage device. In response to the determination that the file exists, the method further comprises mapping the file into a region of a non-volatile dual in-line memory module (NVDIMM); initiating a transaction to write to the mapped file in the NVDIMM without acquiring a speculative lock on the mapped file; and determining whether a conflict occurred in writing to the mapped file in the NVDIMM. In response to a determination that a conflict occurred, the method comprises restarting the transaction to write to the mapped file in the NVDIMM without acquiring the speculative lock on the mapped file. In response to a determination that no conflict occurred, the method comprises committing changes made to the mapped file to the file in the storage device.

Speculative bank activate dynamic random access memory (DRAM) scheduler

A system and associated processes may perform a memory access operation that includes receiving a data packet comprising a command of a type of a plurality of types of commands. The processes may include initiating a decoding of a first portion of the command, and automatically speculating as to the type of the command. Based on the speculation as to the type of the command, a bank activate command may be generated before the data packet is entirely decoded or received.

Reducing resource lock time for a virtual processing unit

Techniques for reducing the probability of spinlock and/or reducing the time that a virtual central processing unit (CPU) may hold a lock are provided. In one embodiment, a computer-implemented method includes determining that an executing virtual CPU is holding a lock for exclusive use of a resource, and scheduling the executing virtual CPU to run for up to a specified time period before de-scheduling the executing virtual CPU. In one embodiment, the executing virtual CPU holding the lock writes a value to a register to indicate that the executing virtual CPU is holding the lock.

Atomic operation predictor to predict if an atomic operation will successfully complete and a store queue to selectively forward data based on the predictor

In an embodiment, a processor comprises an atomic predictor circuit to predict whether or not an atomic operation will complete successfully. The prediction may be used when a subsequent load operation to the same memory location as the atomic operation is executed, to determine whether or not to forward store data from the atomic operation to the subsequent load operation. If the prediction is successful, the store data may be forwarded. If the prediction is unsuccessful, the store data may not be forwarded. In cases where an atomic operation has been failing (not successfully performing the store operation), the prediction may prevent the forwarding of the store data and thus may prevent a subsequent flush of the load.

Distinct system registers for logical processors

Distinct system registers for logical processors are disclosed. In one example of the disclosed technology, a processor includes a plurality of block-based physical processor cores for executing a program comprising a plurality of instruction blocks. The processor also includes a thread scheduler configured to schedule a thread of the program for execution, the thread using the one or more instruction blocks. The processor further includes at least one system register. The at least one system register stores data indicating a number and placement of the plurality of physical processor cores to form a logical processor. The logical processor executes the scheduled thread. The logical processor is configured to execute the thread in a continuous instruction window.

Regulating hardware speculative processing around a transaction

A transaction is detected. The transaction has a begin-transaction indication and an end-transaction indication. If it is determined that the begin-transaction indication is not a no-speculation indication, then the transaction is processed.

Speculative execution management in a coherent accelerator architecture

Disclosed aspects relate to speculative execution management in a coherent accelerator architecture. A first access request from a first component may be detected with respect to a set of memory spaces of a single shared memory in the coherent accelerator architecture. A second access request from a second component may be detected with respect to the set of memory spaces of the single shared memory in the coherent accelerator architecture. The first and second access requests may be processed by a speculative execution management engine using a speculative execution technique with respect to the set of memory spaces of the single shared memory in the coherent accelerator architecture.

Improving latency by performing early synchronization operations in between sets of program operations of a thread

A memory fence or other similar operation is executed with reduced latency. An early fence operation is executed and acts as a hint to the processor executing the thread that executes the fence. This hint causes the processor to begin performing sub-operations for the fence earlier than if no such hint were executed. Examples of sub-operations for the fence include operations to make data written to by writes prior to the fence operation available to other threads. A resolving fence, which occurs after the early fence, performs the remaining sub-operations for the fence. By triggering some or all of the sub-operations for a memory fence that will occur in the future, the early fence operation reduces the amount of latency associated with that memory fence operation.

SPECULATIVE BANK ACTIVATE DYNAMIC RANDOM ACCESS MEMORY (DRAM) SCHEDULER

A system and associated processes may perform a memory access operation that includes receiving a data packet comprising a command of a type of a plurality of types of commands. The processes may include initiating a decoding of a first portion of the command, and automatically speculating as to the type of the command. Based on the speculation as to the type of the command, a bank activate command may be generated before the data packet is entirely decoded or received.

Consolidating read-copy update types having different definitions of a quiescent state

A technique includes monitoring for a quiescent state by checking first quiescent state criteria that are indicative of a CPU having no task running inside an RCU read-side critical section that could be affected by destructive-to-reader actions. If the quiescent state has been reached, a check may be made for the existence of a condition that is indicative of a requirement to satisfy one or more additional quiescent state criteria before reporting the quiescent state on behalf of the CPU. If the condition is detected, reporting of the quiescent state may be deferred until the one or more additional quiescent state criteria are satisfied. The quiescent state may then be reported if it is useful and safe to do so.