Crash consistency persistent memory device and method

Abstract

A data processing apparatus (100) utilizing persistent memory to enable crash-consistent execution is disclosed. The data processing apparatus (100) comprises a persistent memory (105) for storing data. Furthermore, the data processing apparatus (100) comprises a central processing unit (CPU) (101) for executing a program code (107), in which the program code (107) comprises one or more memory access instructions in an instruction set architecture (ISA) of the CPU (101), and a method for operating the data processing apparatus (100), in which the program code (107) comprises one or more memory access instructions in the instruction set architecture (ISA) of the CPU (101). The one or more memory access instructions are used to access the data in the persistent memory (105). The ISA further comprises one or more instructions for a crash consistency execution (CCE) mode of the CPU (101) to implement the CCE of the one or more memory access instructions, and in the CCE mode, the CPU (101) is used for continuing to implement the CCE of the one or more memory access instructions when a read-write conflict occurs.

Description

Technical Field

[0001] The present invention relates to an apparatus and method for information processing technology, and more particularly to an apparatus and method for implementing crash-consistent execution using persistent memory. Background Art

[0002] Persistent memory (PMEM) refers to data structures that can be accessed using memory instructions or memory application programming interfaces (APIs) even after the process that created or ultimately modified them has completed. With PMEM, recoverability is achieved without maintaining a separate copy of the data in memory. On the other hand, the data must remain available after a crash or power outage, which can occur at any time. When a failure occurs during a database modification, such as an insert or delete, the system becomes chaotic, and reusing memory contents is often infeasible due to complexity, cost, and error-proneness. If reusing is possible, the system or data structure is considered crash-consistent. While maintaining volatile shared memory consistency requires locking through atomic operations, crash consistency cannot utilize locks because the system does not attempt to acquire locks before shutting down due to a power outage. Therefore, ensuring the consistency of persistent memory after asynchronous crashes requires novel hardware-assisted mechanisms. Consistency itself is a property of application-specific data, meaning that the application can continue to use that data after a crash. This property derives from the application logic, not the hardware. Summary of the Invention

[0003] It is an object of the present invention to provide improved apparatus and methods for achieving crash-consistent execution using persistent memory.

[0004] The above-mentioned and other objects are achieved by the subject matter of the independent claims. Other implementations are apparent from the dependent claims, the description and the drawings.

[0005] According to a first aspect, a data processing device is provided. The data processing device includes a persistent memory for storing data, and a central processing unit (CPU). The persistent memory can implement a memory hierarchy, including one or more cache memories. The CPU is used to execute program code, in particular, assembly code that defines an application. The program code includes one or more memory access instructions in the instruction set architecture (ISA) of the CPU, and the one or more memory access instructions are used to access the data in the persistent memory. The ISA also includes one or more instructions for the crash-consistent execution (CCE) mode of the CPU to implement atomic CCE of the one or more memory access instructions. In the CCE mode, the CPU is used to continue to implement the CCE of the one or more memory access instructions when a read-write conflict occurs, that is, not to terminate the one or more memory access instructions. Therefore, an improved device is provided, which uses persistent memory to implement crash-consistent execution.

[0006] In yet another possible implementation, in the CCE mode, the CPU is configured to enable concurrent read operations to read committed values ​​without suspending corresponding write operations.

[0007] In another possible implementation, the one or more memory access instructions include one or more memory write instructions for writing data into the persistent memory, and the one or more memory write instructions are in a temporary state when implementing the CCE.

[0008] In another possible implementation, the one or more memory access instructions include one or more memory load instructions for loading data from the persistent memory, and the one or more memory load instructions are used to return the last committed consistency value when an abort occurs.

[0009] In yet another possible implementation, the CPU is a single-threaded (eg, single-core) CPU, the CCE of the one or more memory access instructions starts from a repairable state, and employs one or more temporary writes.

[0010] In yet another possible implementation, when the CCE fails, the CCE cancels the one or more temporary writes to return to the repairable state.

[0011] In yet another possible implementation, the CPU is a multi-threaded (eg, multi-core) CPU, and the CCE of the one or more memory access instructions is used to handle write-write conflicts between different threads in the multiple threads of the CPU.

[0012] In yet another possible implementation, the multiple threads of the CPU observe the write-to-memory instructions in the same order.

[0013] In another possible implementation, the one or more instructions for implementing crash-consistent execution of the one or more memory access instructions include an instruction for marking the start (or initiation) of the CCE of the one or more memory access instructions (referred to herein as a cce_begin instruction). In other words, the cce_begin instruction triggers the CPU to enter CCE mode.

[0014] In another possible implementation, the one or more instructions for implementing crash-consistent execution of the one or more memory access instructions include an instruction for marking the end of the CCE of the one or more memory access instructions (referred to herein as a cce_end instruction). In other words, the cce_end instruction triggers the CPU to return from the CCE mode to the default execution mode.

[0015] In another possible implementation, the one or more instructions of the CCE for implementing the one or more memory access instructions include an instruction (referred to herein as a cce_test instruction) for verifying whether the CPU executes the one or more memory access instructions in the CCE mode.

[0016] In yet another possible implementation, the one or more instructions for implementing the CCE of the one or more memory access instructions include an instruction for suspending the CCE mode (referred to herein as a cce_abort instruction).

[0017] In another possible implementation, the instruction for terminating the CCE mode (ie, cce_abort) further triggers the CPU to issue an error code. The error code may be a number (code) returned by the user of the CCE and interpreted by the application.

[0018] In another possible implementation, in the CCE mode, the CPU is configured to implement a queue (also referred to herein as a reacquisition table) that stores memory addresses associated with read-write conflicts. For example, if a CCE writes to a shared variable X and a concurrent CCE reads shared variable X, the writing CCE is configured to add the address of shared variable X to the queue (i.e., the reacquisition table) to reacquire ownership when the CCE commits.

[0019] According to a second aspect, a method for operating a data processing device is provided. The method comprises the following steps:

[0020] storing data in a persistent memory of the data processing device;

[0021] The CPU in the data processing device executes program code, specifically assembly program code, wherein the program code includes one or more memory access instructions in the instruction set architecture (ISA) of the CPU, and the one or more memory access instructions are used to access the data in the persistent memory. The ISA also includes one or more instructions for the crash-consistent execution (CCE) mode of the CPU to implement atomic CCE of the one or more memory access instructions; in the CCE mode, when a read-write conflict occurs, the CCE of the one or more memory access instructions continues to be implemented (i.e., not aborted).

[0022] The method according to the second aspect of the present invention can be performed by the data processing device according to the first aspect of the present invention. Therefore, the other features of the method according to the second aspect of the present invention are directly implemented by the functions of the data processing device according to the first aspect of the present invention and its different implementations described above and below.

[0023] The details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The embodiments of the present invention are described in detail below with reference to the accompanying drawings, in which:

[0025] Figure 1 A schematic diagram of a data processing apparatus according to an embodiment is shown.

[0026] Figure 2a A schematic diagram illustrating an exemplary memory operation in the form of a tree insertion is shown;

[0027] Figure 2b An exemplary code for a data processing apparatus according to one embodiment is shown to execute in CCE mode. Figure 2a Example memory operations of;

[0028] Figure 3a and Figure 3b Exemplary code for a data processing apparatus according to one embodiment is shown to perform thread-safe write memory operations and thread-safe write memory operations in CCE mode;

[0029] Figure 4a A flowchart illustrating conflict handling implemented by a data processing apparatus according to one embodiment when a read-write conflict occurs is shown;

[0030] Figure 4b A flowchart illustrating conflict handling implemented by a data processing apparatus according to one embodiment when a write-write conflict occurs between two CCEs adopting a requester defeat strategy is shown;

[0031] Figure 4c A flowchart illustrating conflict handling implemented by a data processing apparatus according to one embodiment when a write-write conflict occurs between a CCE and a non-CCE using a requester-wins strategy is shown;

[0032] Figure 5 A table illustrating the differences between CCE and hardware transactional memory implemented by a data processing apparatus according to one embodiment;

[0033] Figures 6a to 6h shows different CCE contention types handled by a data processing apparatus according to one embodiment;

[0034] Figure 7 is a flowchart of a method for operating a data processing apparatus according to one embodiment.

[0035] In the following, identical reference numerals refer to identical or at least functionally equivalent features. DETAILED DESCRIPTION

[0036] In the following description, reference is made to the accompanying drawings which form a part of the present invention, which illustrate, by way of illustration, specific aspects of embodiments of the present invention or specific aspects in which embodiments of the present invention may be used. It should be understood that the embodiments of the present invention may be used in other aspects and include structural or logical changes not depicted in the accompanying drawings. Therefore, the following detailed description should not be understood in a restrictive sense, and the scope of the present invention is defined by the appended claims.

[0037] For example, it should be understood that the disclosure related to describing a method may also apply to a corresponding device or system for performing the method, and vice versa. For example, if one or more specific method steps are described, the corresponding device may include one or more units (e.g., functional units) to perform the one or more method steps described (e.g., one unit performs one or more steps, or multiple units perform one or more of the multiple steps respectively), even if such one or more units are not explicitly described or illustrated in the accompanying drawings. On the other hand, for example, if a specific device is described based on one or more units (e.g., functional units), the corresponding method may include a step to perform the function of one or more units (e.g., one step performs the function of one or more units, or multiple steps perform the function of one or more of the multiple units respectively), even if such one or more steps are not explicitly described or illustrated in the accompanying drawings. In addition, it should be understood that unless otherwise explicitly stated, the features of the various exemplary embodiments and / or aspects described herein may be combined with each other.

[0038] Figure 1 FIG1 shows a schematic diagram of a data processing device 100 according to an embodiment. In one embodiment, the data processing device 100 can be implemented as a cloud server, a mobile device, a tablet computer, a laptop computer, or other types of data processing devices. Figure 1 As shown, the data processing device 100 includes a processing circuit 101 and a memory 105. The processing circuit 101 includes one or more central processing units (CPUs) 101, and the memory 105 includes at least a persistent memory portion for persistently storing data (and may also include other types of memory). Each CPU 101 may include one or more cores. The memory 105 can implement a memory hierarchy, including one or more persistent cache memories that implement a cache consistency protocol such as the MESI protocol. As described in detail below, in one embodiment, the memory 105 is used to ensure that data stored in the CPU cache is flushed to the persistent memory 105 in the event of a power outage.

[0039] The one or more CPUs 101 may be implemented in hardware and / or software and may include digital circuits, or both analog and digital circuits. The digital circuits may include components such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or general-purpose processors. The memory 105 in the data processing device 100 may be used to store executable program code, particularly assembly code 107, which, when executed by the one or more CPUs 101, enables the data processing device 100 to perform the functions and methods described herein. Figure 1 As shown, the data processing device 100 may further include a communication interface 103 , which is configured to communicate via a wired connection and / or a wireless connection.

[0040] As described in detail below, CPU 101 is used to execute program code, in particular, assembly code 107 that defines an application. Assembly code 107 includes one or more memory access instructions in the instruction set architecture (ISA) of the CPU, wherein the one or more memory access instructions are used to access data in persistent memory 105. The ISA also includes one or more instructions for the crash-consistent execution (CCE) mode of CPU 101 to implement atomic CCE of one or more memory access instructions. As described in detail below, in CCE mode, CPU 101 is used to continue to implement CCE of one or more memory access instructions when a read-write conflict occurs, that is, not to abort one or more memory access instructions. In addition, in CCE mode, CPU 101 is used to allow concurrent read operations to read committed values ​​without aborting corresponding write operations. As described herein, if the execution of CPU 101 is crash-consistent execution (CCE), it means that all writes of the execution are persisted and disclosed atomically by CPU 101. Therefore, if an execution moves data from one consistency state to another, the application will be crash consistent.

[0041] Figure 2a An exemplary operation of inserting data into a balanced binary tree is shown, which involves writing to three different pointers (such as Figure 2a According to an embodiment, the data processing apparatus 100 may perform the same operation in the CCE mode so that the operation is the same as Figure 2b The exemplary code 107 shown maintains crash consistency and includes the cce_begin instruction in the ISA of CPU 101, which is used to trigger CPU 101 to enter CCE mode, and the cce_end instruction, which is used to trigger CPU 101 to stop operating in CCE mode. As will be understood from the following detailed description, the crash-consistent persistent memory 105 in the data processing device 100 according to one embodiment is simple to use, highly reliable, and highly secure, and adds negligible overhead to existing multi-core software.

[0042] Other embodiments of the data processing apparatus 100 including crash-consistent persistent memory 105 are described in more detail below. Generally, in CCE mode, when executing code or code segment C 107, the CPU 101 is configured to ensure atomic execution, i.e., all write memory operations are in a temporary state and visible only to the writer until committed. Upon commit, all write memory operations of code segment C 107 are immediately shared and persisted in the cache of memory 105. If execution is aborted before commit (e.g., due to a power outage), the write memory operations are canceled and the state before execution of code segment C 107 is restored.

[0043] It is understandable that although CCE has atomicity, concurrent CCE executions may be interleaved with each other (because CCE is not serializable by design). For example, a first CCE1 may commit and write to a shared variable X, which is in the read set of a concurrent second CCE2. After this event occurs, the second CCE2 proceeds and reads the shared variable X again. Code C may need to be responsible for its own serializability and synchronization. However, according to one embodiment, the CCE mode of the CPU 101 in the data processing device ensures that all atomic instructions can be executed correctly in CCE mode, and the hardware transactional memory (HTM) works correctly with the concurrent CCE, thereby maintaining software serializability and correctness while achieving crash consistency.

[0044] In one embodiment, the ISA of CPU 101 may include one or more of the following instructions for the CCE mode of CPU 101 , ie, for defining and managing code segments that CPU 101 is to execute in a crash-consistent manner.

[0045] In one embodiment, the one or more instructions for implementing crash-consistent execution of one or more memory access instructions include an instruction (referred to herein as a cce_begin instruction) for marking the beginning (i.e., initiation) of a CCE for the one or more memory access instructions by the CPU 101. In other words, the cce_begin instruction triggers the CPU 101 to enter CCE mode. If the CCE mode is successfully entered, the cce_begin instruction may return an acknowledgment, or a dedicated error code if a failure occurs.

[0046] In one embodiment, the one or more instructions for implementing crash-consistent execution of one or more memory access instructions include an instruction (referred to herein as a cce_end instruction) for marking the end of a CCE for the one or more memory access instructions by CPU 101. In other words, the cce_end instruction triggers CPU 101 to return from CCE mode to the default execution mode. In one embodiment, the cce_end instruction may also trigger CPU 101 to share all writes.

[0047] In one embodiment, the one or more instructions for implementing CCE for one or more memory access instructions include an instruction (referred to herein as a cce_test instruction) for verifying (i.e., testing) whether CPU 101 executes the one or more memory access instructions in CCE mode. In one embodiment, the cce_test instruction may trigger CPU 101 to check whether the cce_begin instruction is actually called.

[0048] In one embodiment, the one or more instructions for implementing CCE for one or more memory access instructions include an instruction for terminating CCE mode for CPU 101 (referred to herein as a cce_abort instruction). In one embodiment, the instruction for terminating CCE mode (i.e., the cce_abort instruction) also triggers the CPU to issue a user-defined error code. The error code can be a number (code) returned by the user of CCE and interpreted by the application. In one embodiment, the cce_abort instruction can also trigger CPU 101 to cancel all temporarily stored writes.

[0049] It will be appreciated that the program code 107 of the data processing apparatus 100 according to one embodiment may use the above instructions to define points in the code where the system can be repaired and maintain consistency.

[0050] Figure 2b The exemplary code segment 107 shown shows how CCE implemented by the CPU 101 in the data processing apparatus 100 according to one embodiment adds crash consistency to serial execution by performing all writes atomically. Figure 3a and Figure 3bThe exemplary code 107 shown uses CCE to add crash consistency to a critical section of code (assuming that the section connects two consistency states). To this end, the code in CCE can be protected by a sequential lock. It will be understood that when the value of the sequential lock is even, the lock is in an idle state, and the lock is locked by atomically incrementing the value to the next odd value, and released by incrementing the value to the next even value. The reader can sample the lock before and after the read, and if the lock changes or is an odd number, the reader can retry to obtain a snapshot.

[0051] Figure 3a The exemplary code shown illustrates why Write-Write-Conflict (WWC) aborts implemented by data processing apparatus 100 according to one embodiment are beneficial for correctness. If two concurrent CCEs attempt to acquire the same sequential lock simultaneously (assuming the persistent value of the lock is null), both CCEs may read zero from the lock and successfully write a 1 to the local lock. In this case, both CCEs may enter their critical sections simultaneously, causing mutual exclusion to fail. To address this issue, data processing apparatus 100 according to one embodiment addresses this issue by having the first CCE write a 1 to the lock while simultaneously aborting the second writer. In other words, in one embodiment, CPU 101 in data processing apparatus 100 is configured to implement a "requester-loses" strategy in CCE mode. As will be appreciated, if the second writer aborts the first writer (this also applies to HTMs implementing a "requester-wins" strategy), the first CCE will retry and abort the second CCE, causing the system to enter a livelock state.

[0052] In one embodiment, CPU 101 may be configured to use compare-and-swap (CAS) to ensure atomicity of swaps (since WWC may not add synchronization) to avoid the following scenario: if a normal read is used to check if the lock is idle, and then a normal write is used to lock the lock, there may be a concurrent thread that writes 1 to the lock, acquires the lock, and commits between the read and write, thereby invalidating the mutex.

[0053] Figure 3bThe exemplary code shown utilizes the fact that, according to one embodiment, the CPU 101 in the data processing apparatus 100 can read persistent values ​​in CCE mode even in the presence of concurrent speculative writers. If a read of a critical section completes before a concurrent CCE writer commits, the read may be linearizable before the CCE. If the CCE writer commits before the second sampling of seq_lock, the read may be retried and linearizable after the CCE.

[0054] To illustrate the characteristics of CCE implemented by the CPU 101 in the data processing device 100, the following focuses on comparing some differences between CCE and HTM. HTM has been implemented in several mainstream processor architectures, such as ARM, x86, and POWER PC, and some components of HTM may also be used in CCE. However, while HTM verifies both atomicity and serializability, CCE implemented by the CPU 101 in the data processing device 100 according to one embodiment only requires atomicity. This more relaxed requirement of CCE leads to several differences between CCE and HTM, resulting in CCE implemented by the CPU 101 in the data processing device 100 according to one embodiment having less computational overhead and greater robustness than HTM.

[0055] Figure 5 The table shown highlights some of the key differences between current conventional HTM implementations and the crash-consistent memory embodiment implemented by the data processing apparatus 100. The first fundamental difference lies in the primary goals of HTM and crash-consistent memory. More specifically, the goal of HTM is to implement a lock-free synchronization scheme, while the goal of crash-consistent memory is to implement free recovery. This core design difference means that the CCE implemented by the CPU 101 in the data processing apparatus 100 according to one embodiment does not track loads because these loads are not relevant to recovery. In addition, since the code is assumed to be synchronized, the CCE implemented by the CPU 101 in the data processing apparatus 100 according to one embodiment verifies the linearizability of each memory location, but read-write conflicts (i.e., CCE1 reads variable X, while the variable is being concurrently and speculatively written to CCE2) do not abort any execution, and the software handles the synchronization of X as if the variable were written without the CCE. Compared with HTM, non-tracking reads significantly reduce the resource usage of the CCE implemented by the CPU 101 in the data processing device 100 according to one embodiment, and avoid read-write conflict aborts and most capacity excess aborts, thereby significantly improving the stability of the CCE implemented by the CPU 101 in the data processing device 100 according to one embodiment.

[0056] In one embodiment, only WWCs can trigger aborts to ensure that writes to each memory object maintain a valid order. These aborts can be triggered by CPU 101 using a requester-failure policy, in which the second writer aborts. HTM implementations use a requester-wins policy, in which the last writer completes and the previous writer aborts. When CCE1 writes to a shared variable X and CCE2 concurrently writes to X, CCE2 is the requester. If X is a lock and a requester-wins policy is used, CCE2 aborts CCE1, which immediately retries and terminates CCE2, leading to an infinite loop. Because CCEs typically fully wrap lock-based code, CPU 101 in data processing device 100, according to one embodiment, implements a requester-failure policy for CCE-CCE WWC aborts to avoid this situation. According to the requester-failure policy, if CCE1 acquires the lock X, then when CCE2 attempts to write to X, CCE2 will abort and retry until CCE1 commits, allowing CCE2 to successfully acquire X. This is exactly the expected behavior in lock-based code.

[0057] When the requester is an HTM or a normal write, rather than other CCEs, the CCE implemented by the CPU 101 in the data processing apparatus 100 according to one embodiment can respond according to a requester-wins policy. This may be advantageous because normal writes lack a retry mechanism, while the HTM implements a requester-wins policy. If concurrent threads write to the HTM read set, the HTM no longer maintains consistency.

[0058] Finally, unlike HTM transactions that lack progress guarantees, the small CCE implemented by the CPU 101 in the data processing device 100 according to one embodiment is sized to fit the L1 cache size and associativity of the memory 105 and can be guaranteed to execute successfully in hardware.

[0059] In HTM, critical sections are speculatively written to the private L1 cache, and if a power outage occurs, all speculative writes are canceled. Therefore, HTM is also crash consistent. However, HTM has some requirements that make it unsuitable for crash consistency and rarely used for concurrency control. For example, HTM often aborts due to read-write conflicts, capacity conflicts, and other reasons that can be avoided for crash consistency. Because HTM uses a best-effort mechanism and lacks progress guarantees, it is usually required that each HTM transaction have a software fallback path in case it cannot be successfully executed in hardware. For crash consistency, such a fallback path is unacceptable because in many cases such a path may not exist at all.

[0060] Below Figure 4a 、 Figure 4b and Figure 4cThe microarchitecture implemented by the data processing apparatus 100 is described in the context of FIG. It will be appreciated that, in one embodiment, CCE may be implemented by the CPU 101 according to an HTM using cache memory management. Figure 4a 、 Figure 4b and Figure 4c In the embodiment shown, the data processing device 100 exemplarily implements the MESI cache coherence protocol. Once the CPU 101 (or its core) passes the instruction cce_begin (see Figure 4a 411) enters CCE mode, any internal store can modify the data locally only in the L1 cache memory, which is similar to how HTM handles transactional writes. In one embodiment, the cache line will be updated to the modified state (also called M state in the MESI cache coherence protocol) in the L1 cache and marked with the same w bit as traditional HTM (see Figure 4a 413). If the existing cache line was already in a modified state before the transaction began, it may be written back to the L2 cache memory before the current store is applied to preserve the pre-transactional data. However, unlike HTM, according to one embodiment of data processing apparatus 100, loads do not mark their cache lines with the R bit to avoid tracking read sets and aborting when conflicts occur.

[0061] After the write is complete, any reads by other threads or cores that are performed by snooping the cache line (e.g. Figure 4a 416) will result in a read-after-write scenario (regardless of whether the other thread is in its own CCE mode / transaction). The CCE implemented by CPU 101 in data processing device 100 according to one embodiment may differ from HTM in several aspects of the Modified Exclusive Shared Invalid (MESI) protocol. First, a read-after-write scenario may not be defined as a conflict, thus not aborting the local transaction. Second, an external reader cannot read the locally updated value stored within the CCE transaction.

[0062] The CCE's snoop response is adjusted to "pretend" to miss the L1 cache and instead receive a cache line from the next level of the cache hierarchy (L2 or higher), which holds the pre-transaction value. If no lower-level cache memory holds the cache line, the cache line is read from the main memory of the memory hierarchy 105. This embodiment satisfies the CCE requirement to provide pre-transaction data in any read.

[0063] In one embodiment, the snoop response may include new attributes to force an external reader to receive a cache line in the shared state, even if its read is served by a lower-level cache and could otherwise obtain exclusive ownership. The local cache line will enter the shared state (also known as the S state in the MESI cache coherence protocol) while keeping the w bit valid (see Figure 4a 417), the requester will get the row in the shared state (see Figure 4a 418). Figure 4a As shown, the address of the snooped cache line will be pushed to the dedicated queue 417a (in Figures 4a to 4c 417a) so that the CPU 101 (or its core) executing the transaction can regain exclusive ownership of the cache line again at the end of the transaction. The size of queue 417a may be configurable. For example, queue 417a may hold 8 to 16 entries. If queue 417a is full, CPU 101 may be configured to abort CCE mode. Incoming invalidation snoops may CAM this queue and abort CCE mode if a hit occurs.

[0064] The process described above is as follows Figure 4a As shown in Figure 2, where the value before the transaction is Vp, and the transaction changes the locally stored line to Vt. Other cores / threads that read the cache line will receive the old value (Vp). Once the CCE reaches cce_end (see Figure 4a 423), the CPU 101 in the data processing apparatus 100 according to one embodiment is used to suspend execution and start looping through the reacquisition table 405a. For each address stored in the reacquisition table 405a, the CPU 101 in the data processing apparatus 110 according to one embodiment is used to issue a Read-For-Ownership (RFO) (see Figure 4a 423a), like a regular store, ignores the local copy of the cache line that is available, and waits for the cache line to arrive, thereby validating any other shared copies in other cores. The other copies are guaranteed to hold the old value because other cores cannot silently modify these copies while the line is provided by CPU 101 only in a shared state. This will force any other core that wants to modify the cache line to first try to fetch the cache line (and again peek into the CCE core so it knows there is a real conflict). Since, in one embodiment, stores are to be committed atomically via operations in CCE mode, CPU 101 can be used to issue RFOs in parallel to reduce latency ( Figure 4a Once all cache lines are owned by CPU 101 and retrieval queue 417a is empty, CPU 101 can commit the transaction by removing the w bit in all transaction lines (see Figure 4a 423b) of , making it consistent system-wide.

[0065] Figure 4b A slightly different scenario is shown, where other cores are also writing, resulting in a write-after-write conflict (WWC). In this scenario, the processing performed by CPU 101 can be divided into the following four WWC cases:

[0066] WWC Case 1: If the second (requester) core is in a CCE transaction, then the CCE transaction may be aborted and its changes may be rolled back to ensure the requester failure policy (see Figure 4b 424 and 426), the strategy is implemented by the CPU 101 in the data processing device 100 according to one embodiment (this case is also as Figure 6e shown).

[0067] WWC Case 2: If the second core is in an HTM transaction started earlier, the HTM transaction may be aborted (this case is as follows Figure 6h (as shown) to support the traditional HTM requester win strategy. It will be appreciated that this is an exception to the requester fail strategy implemented by CPU 101 in data processing apparatus 100 according to one embodiment to maintain HTM compatibility and correctness. Due to HTM limitations, this situation also applies to read-write conflicts, i.e., when an HTM transaction only performs reads while a CCE performs writes.

[0068] WWC Case 3: If the second core is in an HTM transaction that was started later than the CCE transaction, then according to the requester failure policy implemented by the CPU 101 in the data processing apparatus 100 according to one embodiment, it may be necessary to abort the local CCE transaction (this case is as follows: Figure 6g shown).

[0069] WWC Case 4: If the second core is not in any transaction, its operation should not be aborted, and the policy implemented by the CPU 101 in the data processing apparatus 100 according to one embodiment may provide that the local core aborts its CCE transaction (this case is as follows: Figure 6f shown).

[0070] To correctly distinguish these situations, the CPU 101 in the data processing device 100 according to one embodiment can be configured to include an additional flag for snoops to indicate that the corresponding snoop originated from a CCE transaction. Therefore, an external invalidation snoop triggered by an RFO issued by another core will only invalidate the local copy and abort the local CCE (corresponding to the above-mentioned WWC situations 2 to 4) if the other core is not in a CCE transaction. If the snoop is marked as a CCE, the snoop is ignored and, upon returning to the other core, the snoop aborts the CCE transaction in the other core.

[0071] Figure 4b The example shown is Figure 4a The example shown is slightly more complex because not only is the cache line written, but it is also read first (see Figure 4b 416, the line is sent in shared mode in 418). It will be appreciated that this means that the snoop is not requesting ownership, but only requesting a shared cache line (assuming modify-to-shared migration is allowed, otherwise it is an invalidated snoop and the behavior is the same as before). In this case, the requester will not abort after reading the load, but will be forced to request ownership of the cache line as soon as it attempts to store a value to the cache line. In one embodiment, when a CCE transaction sees an RFO hit on a shared cache line in the local cache, it can automatically abort (so that no further snooping is required), such as Figure 4b 424 and 426 as shown.

[0072] at last, Figure 4c Shows a write conflict for other non-CCE cores. In this case, as described above, the CPU 101 according to one embodiment may need to abort the local CCE transaction (see Figure 4c 430) because the two writes should not be allowed to proceed simultaneously (otherwise, two cores could acquire the same lock simultaneously, e.g., another core reads data before the CCE, enabling it to enter the critical section in parallel). This is achieved if the other core issues an RFO before writing to the line, which behaves as a snoop, invalidating the local copy in the CCE core (regardless of any previous snoops holding the line in a shared state due to reads). The invalidating snoop hits the reacquisition table 417a and aborts the CCE transaction as expected.

[0073] It should be understood that the concept of CCE correctness is linearizability, not serializability. Therefore, if a CCE store occurs after a concurrent non-CCE store, even if the non-CCE store occurs after the cce_begin instruction, the CCE does not need to be aborted, and the non-CCE store can be linearizable before the CCE because linearizability is implemented on a per-object basis. To demonstrate the correctness of CCE implemented by CPU 101 in data processing device 100 according to one embodiment, the following demonstrates that CCE maintains its progress in executing pure code and preserves hardware linearizability.

[0074] It will be further appreciated that, unlike HTM, which employs a best-effort approach with no progress guarantees and always requires software rollback, any set of CCEs that fit within the L1 cache of memory 105 in data processing apparatus 100 according to one embodiment and are not deadlocked with each other are guaranteed to commit successfully after a finite number of retries. This guarantee is achieved because the requestor failure policy implemented by CPU 101 in data processing apparatus 100 according to one embodiment ensures that if multiple executions attempt to enter a critical section, the first execution to enter will complete the execution of that section, while the remaining executions will retry. According to one embodiment, since reads are not tracked, the size of CCE resource usage is more easily controlled.

[0075] Since the CCE implemented by the CPU 101 in the data processing apparatus 100 according to one embodiment only tracks writes and is less sensitive to contention, CCE can be used to directly completely wrap all operations and make them crash-consistent. This also helps reduce the overhead of CCE instructions (i.e., reduce the number of CCE instructions included in the code). However, if there is potential for severe write-write contention, it may be more advantageous to split the application operations into smaller executions, thereby avoiding unnecessary contention while still keeping the system in a repairable state without the need for logging.

[0076] If the code in a CCE implemented by the CPU 101 in the data processing apparatus 100 according to one embodiment releases a lock but does not terminate the CCE, a concurrent CCE may abort when attempting to lock an idle lock. This can degrade software performance and may introduce more contention or even livelock. Therefore, after releasing the lock, the CPU 101 in the data processing apparatus 100 according to one embodiment can be used to terminate the CCE. If a CCE aborts, it may be retried from the beginning, so it is best to start the CCE from the lock acquisition to avoid retrying the read-only prefix. However, since the read-only prefix does not increase contention, it is sometimes more convenient to directly restart the CCE to split a large operation into smaller parts without skipping the read-only prefix.

[0077] Linearizability is a widely accepted concept of correctness, and recent research has shown that a standard definition can be used to prove the correctness of hardware weak memory models. Linearizability implies that every object has a sequential history, or in the case of CCE implemented by CPU 101 in data processing apparatus 100 according to one embodiment, every address has a global write order. To prove that CCE implemented by CPU 101 in data processing apparatus 100 according to one embodiment is correct, it is necessary to prove the following: (a) CCE is linearizable, (b) HTM and ordinary writes concurrent with CCE remain linearizable, and (c) HTM maintains serializability in the presence of CCE. It is understood that linearizability is a non-blocking correctness condition for concurrent objects, meaning that linearizability itself never requires a thread to wait for other threads to complete ongoing operations. Furthermore, linearizability exhibits locality, meaning that objects composed of linearizable objects are themselves linearizable. It is necessary to verify that, during a CCE commit implemented by the CPU 101 in the data processing apparatus 100 according to one embodiment, i.e., after calling the cce_end instruction, all addresses are linearizable, and that each address remains linearizable even after a failure. Since commit always preserves the last committed persistent value, it is sufficient to prove that all addresses are linearizable after the commit is complete.

[0078] If each CCE implemented by the CPU 101 in the data processing apparatus 100 according to one embodiment writes to a different address, then all addresses are easily linearizable. Therefore, if there is an inconsistency, it occurs when there is a conflict, i.e., two concurrent executions write to the same address. For ease of illustration, it is assumed that each conflicting execution writes to the address once, but if there are several writes to the same address in a CCE, they can be linearized sequentially. Figure 6 shows all possible conflict scenarios, using the following notation: A = abort; C = committed_xend (HTM) or cce_end; R = read from shared variable X; W = write to shared variable X.

[0079] In one embodiment, under a conflict scenario, the shared variable X remains linearizable in the CCE implemented by the CPU 101 in the data processing apparatus 100 according to one embodiment, and remains serializable in the HTM and normal access. Normal access serializability is obvious. Figure 6b In , a normal read before CCE commits reads the shared variable X before the write commits, so the normal read strictly happens before the write, and in Figure 6f In , normal writes abort CCE, so this situation is also obvious.

[0080] For concurrent HTM transactions, it can be proven that not only the linearizability of the shared variable X is maintained, but also the serializability of the transactions is maintained. Figure 6c In

[15] , the HTM reads after the speculative write is executed in the CCE but before the CCE commits, and the HTM completes the commit before the CCE commits, so the read is serialized before the write.

[0081] Figure 6d The initial stage and Figure 6c Similarly, the HTM read observes the persisted value, but the CCE commits and sends a snoop during the re-fetch phase, which causes the HTM to abort, but serializability is not affected. This is important because the CCE implemented by the CPU 101 in the data processing device 100 according to one embodiment commits writes on the HTM read set, which does violate serializability.

[0082] exist Figure 6g In

[15] , the HTM write occurs after the CCE write, so the HTM aborts the CCE according to the traditional HTM requester wins strategy.

[0083] exist Figure 6h In the embodiment, the CCE implemented by the CPU 101 in the data processing apparatus 100 is written after the HTM access, so the snoop sent by the CCE implemented by the CPU 101 in the data processing apparatus 100 according to one embodiment will abort the HTM (again according to the requester wins policy of the HTM).

[0084] Therefore, it is still necessary to verify that X is linearizable in the CCE implemented by the CPU 101 in the data processing apparatus 100 according to one embodiment. Figure 6a The conflict shown is a special case because the conflicting read (Rc in the right CCE) occurs after the speculative write (Ws in the left CCE). This is acceptable, so the commit succeeds because Rc reads the persisted value and can therefore be linearized before Ws commits. The entire CCE is not serializable, and if software requires serializability, it may need to add synchronization (e.g., locks) to protect itself.

[0085] If a conflicting write (such as Figure 6e ) occurs in a concurrent CCE, then after the speculative write, the concurrent CCE will abort using the requestor failure strategy implemented according to the embodiments disclosed herein. It can be seen by observation that in all WWCs (i.e. Figures 6d to 6h In the scenario described above, there is never more than one speculative value for the shared variable X at the same point in time. Therefore, the overall global order of all writes to the shared variable X can be determined, i.e., the order in which the CCEs that successfully wrote to X were committed.

[0086] It can be understood that according to one embodiment, the atomic operations within the CCE implemented by the CPU 101 in the data processing device 100 (for example, compare and switch or extract and add) are no different from ordinary writes. When a conflict occurs, only the first operation is completed, thereby ensuring linear consistency.

[0087] Figure 7 is a flowchart of a method 700 for operating a data processing apparatus 100 according to one embodiment.

[0088] The method 700 includes step 701 : storing data in the persistent memory 105 in the data processing device 100 .

[0089] Furthermore, method 700 includes step 703: CPU 101 in data processing apparatus 100 executes program code, where the program code includes one or more memory access instructions in an instruction set architecture (ISA) of CPU 101, where the one or more memory access instructions are used to access data in persistent memory 105. As described above, the ISA of CPU 101 also includes one or more instructions for a crash-consistent execution (CCE) mode of CPU 101 to implement CCE of the one or more memory access instructions; in CCE mode, when a read-write conflict occurs, the CCE of the one or more memory access instructions continues to be implemented.

[0090] Since the method 700 can be implemented by the data processing device 100 , other features of the method 700 are directly implemented by the functions of the data processing device 100 and its different embodiments described above and below.

[0091] Those skilled in the art will understand that the "boxes" ("units") in the various figures (methods and devices) represent or describe the functions of an embodiment of the present invention (and not necessarily independent "units" in hardware or software), thereby equally describing the functions or features of the device embodiments and the method embodiments (unit = step).

[0092] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described are merely exemplary. For example, unit division is merely a logical functional division, and other division methods can be used in actual implementation. For example, multiple units or components can be merged or integrated into another system, or some features can be ignored or not performed. In addition, the mutual coupling or direct coupling or communication connection shown or described can be implemented through some interfaces. The indirect coupling or communication connection between devices or units can be implemented through electronic, mechanical or other forms.

[0093] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, may be located in one location, or may be distributed across multiple network units. Some or all of the units may be selected as needed to achieve the purpose of the embodiment.

[0094] In addition, the functional units in the embodiments disclosed herein may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

Claims

1. A data processing device (100), characterized in that: include: Persistent memory (105), for storing data; a central processing unit (CPU) (101) for executing a program code (107), wherein the program code (107) includes one or more memory access instructions in an instruction set architecture (ISA) of the CPU (101), the one or more memory access instructions being used to access the data in the persistent memory (105); The ISA further includes one or more instructions for a crash-consistent execution (CCE) mode of the CPU (101) to implement CCE of the one or more memory access instructions; In the CCE mode, the CPU (101) is configured to continue implementing the CCE of the one or more memory access instructions when a read-write conflict occurs.

2. The data processing device (100) according to claim 1, characterized in that In the CCE mode, the CPU (101) is used to enable concurrent read operations to read committed values ​​without suspending corresponding write operations.

3. The data processing device (100) according to claim 1 or 2, characterized in that The one or more memory access instructions include one or more memory write instructions for writing data into the persistent memory (105), and the one or more memory write instructions are in a temporary state when the CCE is implemented.

4. The data processing device (100) according to any one of the preceding claims, characterized in that The one or more memory access instructions include one or more memory load instructions for loading data from the persistent memory (105), and the one or more memory load instructions are used to return the last committed consistency value when an abort occurs.

5. The data processing device (100) according to any one of the preceding claims, characterized in that The CPU (101) is a single-threaded CPU (101), and the CCE of the one or more memory access instructions starts from a repairable state and uses one or more temporary writes.

6. The data processing device (100) according to claim 5, characterized in that When the CCE fails, the CCE cancels the one or more temporary writes to return to the repairable state.

7. The data processing device (100) according to any one of claims 1 to 4, characterized in that: The CPU (101) is a multi-threaded CPU (101), and the CCE of the one or more memory access instructions is used to handle write-write conflicts between different threads in the multiple threads of the CPU (101).

8. The data processing device (100) according to claim 7, characterized in that The multiple threads of the CPU (101) read the write memory instructions in the same order.

9. The data processing device (100) according to any one of the preceding claims, characterized in that The one or more instructions for implementing a CCE for the one or more memory access instructions include an instruction for marking a start of the CCE for the one or more memory access instructions.

10. The data processing device (100) according to any one of the preceding claims, characterized in that The one or more instructions for implementing a CCE for the one or more memory access instructions include instructions for marking an end of the CCE for the one or more memory access instructions.

11. The data processing device (100) according to any one of the preceding claims, characterized in that The one or more instructions for implementing CCE for the one or more memory access instructions include instructions for verifying whether the CPU executes the one or more memory access instructions in the CCE mode.

12. The data processing device (100) according to any one of the preceding claims, characterized in that The one or more instructions for implementing CCE for the one or more memory access instructions include instructions for suspending the CCE mode.

13. The data processing device (100) according to claim 12, characterized in that The instruction for suspending the CCE mode also triggers the CPU (101) to issue an error code.

14. The data processing device (100) according to any one of the preceding claims, characterized in that In the CCE mode, the CPU (101) is used to implement a queue, and the queue is used to store memory addresses associated with read-write conflicts.

15. A method (700) for operating a data processing device (100), characterized in that The method (700) comprises: Storing (701) data in a persistent memory (105) of the data processing device (100); A CPU (101) in the data processing device (100) executes (703) a program code (107), wherein the program code (107) includes one or more memory access instructions in an instruction set architecture (ISA) of the CPU (101), the one or more memory access instructions being used to access the data in the persistent memory (105), and the ISA also including one or more instructions for a crash-consistent execution (CCE) mode of the CPU (101) to implement CCE of the one or more memory access instructions; in the CCE mode, when a read-write conflict occurs, the CCE of the one or more memory access instructions continues to be implemented.

Images