Accelerating transactional processing

Abstract

In some examples, a method for accelerating transaction execution in a system comprising an accelerator for performing cache- coherent operations and a persistent storage is provided.

Description

[0001] ACCELERATING TRANSACTIONAL PROCESSING

[0002] TECHNICAL FIELD

[0003] The present disclosure relates, in general, to accelerating transaction execution in computer systems. Aspects of the disclosure relate to reducing transaction latency and contention between concurrent transactions through the use of a transactional accelerator and asynchronous writes to persistent storage.

[0004] BACKGROUND

[0005] Write operations on stable storage devices, such as hard disk drives (HDD), solid-state drives (SSD), or storage-class memory (SCM), including phase-change memory (PCM), 3D XPoint, magnetic RAM (MRAM), and resistive RAM (ReRAM), often involve modifying multiple disk sectors or cache lines at a time. These operations, when performed by applications or operating systems, typically do not guarantee crash consistency or failure atomicity by default. This is due to the architecture of modem computing systems, including those based on x86 or ARM processors, where the CPU does not directly perform write operations to memory or storage. Instead, write operations are first carried out in the CPU cache, and the data is later propagated to the target memory or storage. As a result, if a failure occurs - for example, a power outage or an operating system crash - during the execution of a write operation, the system may enter an inconsistent state. This inconsistency may render the system unrecoverable upon restart, as the changes made by the writes may not have been fully written or committed to persistent storage.

[0006] To support crash consistency, several programming techniques have been developed, such as transactional processing, checkpointing, and journaling. These techniques leverage low-level guarantees provided by the hardware, which ensures that individual write operations to disk sectors, memory words, and other units of data are performed reliably. Among these techniques, transactional processing has become a widely used method for achieving crash consistency in systems that utilise persistent storage such as storage-class memory, which serves as the focus of this specification. Transactional processing ensures certain guarantees, including atomicity, consistency, and durability. Atomicity ensures that either all transaction operations succeed, or none of them do. Consistency guarantees that the execution of the transaction moves the system from one consistent state to another, while durability ensures that once a transaction is committed, the changes it introduces are preserved, even in the event of a failure.

[0007] Due to spatial and temporal locality in data accesses, CPU caches mitigate the performance cost of memory reads and writes performed during transactions. However, the dominant performance bottleneck in transaction execution arises from the need for synchronous writes to persistent storage, which typically require flush and store fence (for example, for x86-based systems, clwb and sfence) operations. These operations, although necessary for ensuring durability and consistency, introduce significant latency and can substantially slow down the overall performance of transactions. This high latency of transaction execution presents a significant challenge, particularly in high-performance systems where the speed of transaction processing is crucial. Finding methods to reduce this latency while maintaining crash consistency and durability guarantees remains a critical area of interest in the field.

[0008] SUMMARY

[0009] An objective of the present disclosure is to reduce transaction latency and contention between the concurrent transactions.

[0010] The foregoing and other objectives are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the Figures.

[0011] A first aspect of the present disclosure provides a method for accelerating transaction execution in a system comprising an accelerator for performing cache-coherent operations and a persistent storage, the method comprising receiving, by a processor, a request to modify data stored in the persistent storage as part of a transaction, creating, by the processor or the accelerator, a transaction identifier associated with the request, and at least one persistent log entry for an object to be modified as part of the transaction, wherein a log entry is based on a type of log used, determining, by the accelerator, a set of addresses of cache lines in a memory of an accelerator, wherein the cache lines in the memory of the accelerator are cache lines to be modified as part of the transaction, receiving or retrieving, by the accelerator, data associated with the request from the CPU or persistent storage, and transferring the data to corresponding cache lines within the memory of the accelerator, performing, using the accelerator or the processor, the requested modification on the data in the memory of the accelerator, thereby generating multiple modified cache lines, buffering, by the accelerator, the multiple modified cache lines in a memory of the accelerator until the associated initial log entries for the objects to be modified have been written to the persistent storage, writing, by the accelerator, log entries to persistent storage, such that the old or new values, depending on the log type, are persisted before committing changes, writing, by the accelerator, the modified data from the memory of the accelerator to the corresponding locations in the persistent storage, removing, by the accelerator, the log entries and the corresponding data in the memory of the accelerator once the modified data has been persisted to the memory and the logs are no longer needed, and allowing, by the accelerator, the CPU to proceed with subsequent operations upon acknowledgment of completion of required steps in log creation or data persistence.

[0012] Asynchronous log entry flushes to a persistent storage are thus enabled along with transactional write operation buffering. Accordingly, the latency of transactional execution is reduced, along with a reduction of the contention between concurrent transactions, which has the advantage of increasing system throughput.

[0013] Since only software libraries that facilitate transactional processing need be adapted, the method is transparent to the end application, i.e., the application that executes the transaction.

[0014] In an implementation of the first aspect, determining the set of addresses of cache lines in the memory of the accelerator and the corresponding persistent storage locations can comprise calculating an offset based on a difference between a starting address of the memory of the accelerator and a starting address within the persistent storage. The calculated offset can be applied by the accelerator to determine the corresponding persistent storage locations for each modified cache line in the memory of the accelerator.

[0015] In an example, the accelerator can copy only the modified cache lines to the corresponding persistent storage locations based on the calculated offset. Determining the set of addresses of cache lines in the memory of the accelerator and the corresponding persistent storage locations can comprise the use of a hash table stored in the memory of the accelerator to facilitate lookups of the corresponding persistent storage addresses. The data associated with the request can be organised within a tracking data structure within the memory of the accelerator, and the tracking data structure can be arranged to enable the accelerator to identify which cache lines within the memory of the accelerator have been written to during the requested modification. Removing, by the accelerator, the log entries and the corresponding data in the memory of the accelerator once the modified data has been persisted to the memory and the logs are no longer needed can comprise asynchronously destroying, by the accelerator, log entries stored in the persistent storage after the modified data has been successfully persisted and confirmed as no longer needed. Allowing, by the accelerator, the CPU to proceed with subsequent operations upon acknowledgment of completion of required steps in log creation or data persistence can comprise sending, by the accelerator to the CPU, an early acknowledgment indicating that the accelerator has initiated asynchronous creation of a log entry associated with the requested modification. A second aspect of the present disclosure provides an apparatus for accelerating transaction execution in a system comprising an accelerator for performing cache-coherent operations and a persistent storage, the apparatus comprising an accelerator arranged to receive a request to modify data stored in the persistent storage as part of a transaction, create a transaction identifier associated with the request and generate an initial log entry in the persistent storage for each object to be modified by the transaction, determine, using the accelerator, a set of addresses of cache lines in a volatile memory of the accelerator and corresponding addresses in the persistent storage, transfer data associated with the request from the persistent storage to the corresponding cache lines within the accelerator's volatile memory, perform the requested modification on the data in the volatile memory, resulting in multiple modified cache lines, buffer the modified cache lines in a memory of the accelerator until the associated initial log entries have been written to the persistent storage, generate, for each modified object, a further log entry in the persistent storage, wherein each further log entry reflects the value of the modified data in the volatile memory, write the modified data from the volatile memory to the corresponding locations in the persistent storage, and remove each further log entry for a modified object once the modified data has been written to the persistent storage.

[0016] In an implementation of the second aspect, the accelerator can determine the set of addresses of cache lines in the memory of the accelerator and the corresponding persistent storage locations by calculating an offset based on a difference between a starting address of the memory of the accelerator and a starting address within the persistent storage. The accelerator can apply the calculated offset to determine the corresponding persistent storage locations for each modified cache line in the memory of the accelerator. The accelerator can copy only the modified cache lines to the corresponding persistent storage locations based on the calculated offset. The accelerator can use a hash table stored in the memory of the accelerator to facilitate lookups of the corresponding persistent storage addresses. The accelerator can asynchronously destroy log entries stored in the persistent storage after the modified data has been successfully persisted and confirmed as no longer needed. The accelerator can send, to the CPU, an early acknowledgment indicating that the accelerator has initiated asynchronous creation of a log entry associated with the requested modification.

[0017] These and other aspects of the disclosure will be apparent from the embodiments) described below.

[0018] BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order that the present disclosure may be more readily understood, embodiments of the disclosure will now be described, by way of example, with reference to the accompanying drawings, in which:

[0020] Figure 1 is a flow chart of a method for accelerating transaction execution in a system comprising an accelerator for performing cache-coherent operations and a persistent storage according to an example;

[0021] Figure 2 is a representation of an execution flow of a transaction backed by an undo log according to an example;

[0022] Figure 3 is a representation of an execution flow of a transaction backed by a redo log according to an example;

[0023] Figure 4 is a representation of an execution flow of a transaction backed by a redo log according to another example; and

[0024] Figure 5 is a schematic representation of an architecture of a transactional accelerator. DETAILED DESCRIPTION

[0025] Example embodiments are described below in sufficient detail to enable those of ordinary skill in the art to embody and implement the systems and processes herein described. It is important to understand that embodiments can be provided in many alternate forms and should not be construed as limited to the examples set forth herein.

[0026] Accordingly, while embodiments can be modified in various ways and take on various alternative forms, specific embodiments thereof are shown in the drawings and described in detail below as examples. There is no intent to limit to the particular forms disclosed. On the contrary, all modifications, equivalents, and alternatives falling within the scope of the appended claims should be included. Elements of the example embodiments are consistently denoted by the same reference numerals throughout the drawings and detailed description where appropriate.

[0027] The terminology used herein to describe embodiments is not intended to limit the scope. The articles “a,” “an,” and ‘The” are singular in that they have a single referent, however the use of the singular form in the present document should not preclude the presence of more than one referent. In other words, elements referred to in the singular can number one or more, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and / or “including,” when used herein, specify the presence of stated features, items, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, items, steps, operations, elements, components, and / or groups thereof.

[0028] Unless otherwise defined, all terms (including technical and scientific terms) used herein are to be interpreted as is customary in the art. It will be further understood that terms in common usage should also be interpreted as is customary in the relevant art and not in an idealized or overly formal sense unless expressly so defined herein.

[0029] The execution of transactions in modem computing systems is crucial for ensuring consistency and durability, especially when working with persistent storage such as storage-class memory (SCM). Two primary types of transactional approaches are commonly used: undo-log-based transactions and redo-log-based transactions. Undo-log-based transactions involve storing the previous state of an object before performing any write operations, allowing the system to roll back changes if a failure occurs during the transaction. In contrast, redo-log-based transactions focus on storing the changes that will be applied, ensuring that they can be reapplied in case of a failure, thus completing the transaction.

[0030] Despite their widespread use, these transactional models face significant performance challenges, particularly when executing on systems with persistent storage. One of the main issues is the high latency associated with synchronous writes to SCM, which are necessary to maintain transaction integrity. This latency arises due to the need to flush data and log entries from the CPU cache to persistent storage, a process that often involves multiple steps, such as flushing transaction metadata, log entries, and updated object values. For transactions backed by undo logs, this can result in multiple write operations to the persistence domain (proportional to the number of objects updated in the transaction), while redo logs also incur significant overhead due to the need to persist log entries and updated objects.

[0031] In an effort to address these performance issues, several prior art solutions have been proposed. For example, solutions like PAX and NearPM have been developed to optimise the execution of writes to persistent storage, with a particular focus on managing the persistence of data structures and transaction logs. However, these approaches are either not general solutions or suffer from severe limitations. For example, PAX does not support general-purpose transactions, and lacks robust support for concurrent use. For example, NearPM requires that some modifications are made to the memory device (their approach cannot be integrated with the host or an intermediate device between the host and the memory device, such as a CXL switch) and also does not support native load / store semantics within transactions. Other existing approaches aim to improve transaction performance by manipulating the CPU cache and volatile memory, but they also come with drawbacks, such as increased strain on the CPU cache subsystem due to additional copies of transactional data, or requiring complex mappings between DRAM and SCM, therefore increasing computational expense.

[0032] To address the limitations of these prior art solutions, the present disclosure introduces a novel approach for accelerating transaction execution by reducing the latency of transaction processing. Specifically, the disclosure enables asynchronous log entry flushes and buffers transactional write operations to persistent storage, significantly decreasing the time required to execute transactions. This approach not only reduces latency, but also alleviates contention between concurrent transactions, thereby improving overall system throughput.

[0033] A key aspect of the present disclosure is the use of a transactional accelerator that operates in close proximity to the memory system, such as on the CPU, a memory module, or an intermediate device (for example, a CXL switch). The accelerator manages transaction logs and write operations by asynchronously flushing log entries to persistent storage and buffering write operations until the log entries are safely stored. While this system is transparent to the end application, meaning no modifications to the application code are required, libraries used by the programmers may need to be updated to fully leverage the benefits of the new hardware. By offloading some of the transactional processing to the accelerator, the system achieves improved performance, without requiring hardware changes to the CPU itself.

[0034] Additionally, the disclosure supports both undo and redo log-based transactions. For undo log-based transactions, the disclosure allows for parallel persistence of log entries and object updates for different objects modified by the transaction (that is, for object x, persistence of its log entry and its update needs to happen sequentially), with log destruction happening asynchronously. In the case of redo log-based transactions, the disclosure ensures that the log entry is written to SCM before any updates to objects in SCM are performed. However, updates in the CPU caches can occur in parallel with the creation of the log entry, as long as the updates are buffered until the log entry is created. This reduces the number of synchronous writes to SCM and thus accelerates transaction execution. As such, the system and method described herein offer a substantial reduction in transaction execution time, benefitting applications that rely on persistent storage for transaction processing, without requiring any changes to their codebase.

[0035] Examples in the present disclosure can be provided as methods, systems or machine-readable instructions, such as any combination of software, hardware, firmware or the like. Such machine-readable instructions may be included on a computer readable storage medium (including but not limited to disc storage, CD-ROM, optical storage, etc.) having computer readable program codes therein or thereon.

[0036] The present disclosure is described with reference to flow charts and / or block diagrams of the method, devices and systems according to examples of the present disclosure. Although the flow diagrams described above show a specific order of execution, the order of execution may differ from that which is depicted. Blocks described in relation to one flow chart may be combined with those of another flow chart. In some examples, some blocks of the flow diagrams may not be necessary and / or additional blocks may be added. It shall be understood that each flow and / or block in the flow charts and / or block diagrams, as well as combinations of the flows and / or diagrams in the flow charts and / or block diagrams can be realized by machine readable instructions.

[0037] Figure 1 is a flow chart of a method for accelerating transaction execution in a system comprising an accelerator for performing cache-coherent operations and a persistent storage according to an example. The method comprises, in block 101, receiving, by a processor, a request to modify data stored in the persistent storage as part of a transaction. As used herein, the term "persistent storage" relates to a class of memory storage that retains data even when power is removed. Persistent storage may comprise, for example, storage-class memory technologies such as phase-change memory, resistive RAM, or spin-transfer torque RAM. The request to modify data may relate to a variety of operations, including updates, deletions, or insertions into persistent storage. The data being modified as part of the transaction may comprise complex data structures, such as arrays, lists, database entries, hash tables, or other structures optimised for fast lookups and data organisation, or simpler scalar variables. Concrete data structures, such as hash tables or radix trees, may be used within the accelerator to facilitate quick access to the relevant internal state, including identifying the new or old value of the cache lines. Lookups may be performed in parallel across partitioned internal states to reduce latency further. The transaction itself may comprise operations that need to be consistent and atomic - that is, operations which require that, in the event of a failure, either all changes are applied, or none.

[0038] In block 102, the method comprises creating, by the processor or the accelerator, a transaction identifier associated with the request, and at least one persistent log entry for an object to be modified as part of the transaction, wherein a log entry is based on a type of log used. The transaction identifier may comprise a unique value or structure designed to associate all operations performed within the transaction. The log entry created may depend on whether an undo log or a redo log are used. Log entry creation can occur explicitly (for example, through a programmer’s call to an add_to_log() function or routine), or it may occur speculatively. For speculative creation, existing methods (for example, as described in Ye, Chencheng, et al. "SpecPMT: Speculative logging for resolving crash consistency overhead of persistent storage. " Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2. 2023) could be utilised. The method may also comprise assigning metadata (for example, timestamps) to the log entries to track their order and relevance. In case of a system failure occurring, this metadata may be used to aid the recovery process.

[0039] In addition to identifying transaction operations, the accelerator may also track the state of log entries, ensuring incomplete entries are appropriately handled before allowing further operations. The CPU may wait with subsequent operations until the accelerator indicates that the CPU can proceed; such an indication may comprise, for example, an acknowledgement of log creation, or an indication that the accelerator will create a log entry and buffer the corresponding writes until it happens.

[0040] In block 103, the method comprises determining, by the accelerator, a set of addresses of cache lines in a memory of an accelerator, wherein the cache lines in the memory of the accelerator are cache lines to be modified as part of the transaction. The set of addresses may be determined using mappings stored in the accelerator’s memory or by querying the CPU or memory subsystem. The internal state of the accelerator may be partitioned, allowing lookups to occur simultaneously across multiple partitions.

[0041] The determination of cache line addresses may also comprise, if the accelerator is part of the cache coherence domain of the host, checking coherence states (e.g., whether the cache line in the accelerator’s memory is in the modified, exclusive, shared or invalid state). If updates arrive before the log entries are fully created, these updates may be temporarily buffered until the logs are ready, ensuring no modification is lost.

[0042] In block 104, the method comprises receiving or retrieving, by the accelerator, data associated with the request from the CPU or persistent storage, and transferring the data to corresponding cache lines within the memory of the accelerator. The retrieval of data may comprise direct memory access techniques or any other suitable transfer protocols optimised for high-speed operations; for this, the cache coherence mechanism may also be used. Data may be fetched in chunks or batches, depending on the size and type of the transaction. The transfer to cache lines may comprise mechanisms to avoid overwriting uncommitted data.

[0043] In block 105, the method comprises performing, using the accelerator or the processor, the requested modification on the data in the memory of the accelerator, thereby generating multiple modified cache lines. The modifications may be arithmetic, logical, or structural, depending on the type of data and the requested operation. The accelerator may perform these modifications in parallel, leveraging its hardware capabilities to increase efficiency. The generation of modified cache lines may involve marking these lines with special flags or states indicating that they contain updated data yet to be persisted, making it easier to track the modifications made to the data.

[0044] In block 106, the method comprises buffering, by the accelerator, the multiple modified cache lines in a memory of the accelerator until the associated initial log entries for the objects to be modified have been written to the persistent storage. Buffering the modified cache lines may comprise storing them in a reserved area of the accelerator's memory, which may be volatile or non-volatile, depending on the implementation.

[0045] Coalescing writes to the same cache line may also be performed during this phase. For example, in an undo-log-based transaction, if the same cache line is modified multiple times within a transaction, only the final version of the cache line is written to persistent storage during the commit phase, reducing unnecessary duplication and improving efficiency. Once a log entry is created with the old value of the cache line, subsequent updates to the same cache line do not require additional log entries. Instead, just before the transaction is committed, the final version of the modified cache line is written to storage.

[0046] The accelerator may buffer (for example, in a pending store buffer) all subsequent stores to cache lines modified by a transaction that committed, but whose log has not yet been destroyed. The accelerator may therefore also serve, from the pending store buffer, all subsequent loads to cache lines modified by a transaction that committed, but whose log has not yet been destroyed. Advantageously, the accelerator can therefore ensure that no data is written to persistent storage prematurely, as premature writing to persistent storage might break the consistency of data. Importantly, load operations issued to persistent storage (SCM) may occur in parallel with checks performed by the accelerator on its internal state, reducing the latency of serving read requests.

[0047] In block 107, the method comprises writing, by the accelerator, log entries to persistent storage, such that the old or new values, depending on the log type, are persisted before committing changes. The process of writing log entries to persistent storage may comprise issuing specific flush or write-back instructions, therefore ensuring durability of the data (i.e., that it does not disappear in the event of a failure).

[0048] Various techniques such as grouping writes or employing asynchronous techniques may be utilised for the writing process, thereby minimising latency. The accelerator can acknowledge the completion of this step early to the CPU, enabling the processor to initiate subsequent transactions or unrelated operations while the logs persist in the background.

[0049] In block 108, the method comprises writing, by the accelerator, the modified data from the memory of the accelerator to the corresponding locations in the persistent storage. Additionally, during this phase, any additional buffered cache line updates (present in the accelerator’s buffer) may be flushed and persisted to ensure that the transaction is entirely committed.

[0050] The writing of modified data may further comprise performing checks to ensure that the persistent storage is updated atomically and consistently, especially in systems with multiple memory nodes or modules. The method may further comprise employing strategies to detect and handle conflicts or inconsistencies during the write operation, further ensuring the integrity of the operation.

[0051] In block 109, the method comprises removing, by the accelerator, the log entries and the corresponding data in the memory of the accelerator once the modified data has been persisted to the memory and the logs are no longer needed. Advantageously, the removal may be performed asynchronously, ensuring that system performance is not significantly impacted while cleaning up residual data.

[0052] In block 110, the method comprises allowing, by the accelerator, the CPU to proceed with subsequent operations upon acknowledgment of completion of required steps in log creation or data persistence. The acknowledgment to the CPU may comprise signalling mechanisms, such as interrupts or completion flags, that inform the processor that it can resume its operations. The subsequent operations may include initiating new transactions or handling unrelated tasks that were pending during the transactional execution. Crucially, this enables the CPU to carry on with objects updates while the log entries are being created.

[0053] To aid understanding of the above-described process, reference will now be made to Figures 2-4, depicting the execution flow of transactions backed by different logs.

[0054] Figure 2 is a representation of an execution flow of a transaction backed by an undo log according to an example. The flow depicts the interaction between three layers: the CPU (host) 201, the accelerator (ACC) 202, and the SCM (storage-class memory, i.e., persistent storage) 203. The skilled person would appreciate that the terms “host” and “CPU” refer to the same element and can be used interchangeably.

[0055] The transaction may start when the CPU 201 creates a transaction identifier tx, which may be referenced throughout the transaction's lifecycle. The CPU 201 may perform an add to logQ operation for an object to be updated within the transaction. The CPU 201 may issue a request to the accelerator 202 to create an undo log entry, providing details of the cache lines to be backed up.

[0056] The accelerator 202 may check the state of the cache lines within the cache coherence domain. If the SCM 203 holds the most recent value (shared ("5") state, or exclusive ( “E”) state), the accelerator 202 may copy this value to its static random-access memory (SRAM); otherwise, the accelerator 202 may fetch the value from the CPU cache. Once the mapping in SRAM is created, the accelerator 202 may write the undo log entry asynchronously to SCM 203, and acknowledge completion to the CPU 201. The undo log entry may comprise a cache line address and the value that has just been obtained. This process may repeat for each object update (#1 to #6 in the figure), with the CPU 201 awaiting acknowledgment before proceeding to the next step.

[0057] The CPU 201 may perform in-place updates to the cache lines of the objects within the transaction. These updates may initially be stored in the CPU cache. When cache lines are evicted, the accelerator 202 may intercept these updates and buffers them in its SRAM (pending store buffer) until the corresponding log entry is persisted in SCM 203. Subsequent updates to the same cache lines may be delayed until log persistence is ensured while load operations from these cache lines are served using the pending store buffer.

[0058] Before the transaction can commit, the CPU 201 may flush all updated cache lines to the accelerator 202. This may involve issuing explicit flush commands (e.g., clwb and sfence) or responding to accelerator-initiated fetch requests. Importantly, the accelerator 202 may ensure all cache lines are in a coherent state (e.g., "S" or "E") before writing them to SCM 203.

[0059] Once updates and log entries are fully persisted in SCM 203, the accelerator 202 may mark the log as invalid and destroy it asynchronously. During this process, subsequent store operations to cache lines modified in the transaction may continue to be buffered. The transaction ends when the host 201 receives an acknowledgment of the commit from the accelerator 203.

[0060] If an error occurs, the transaction may be aborted, and the undo log will enable the system to roll back changes. After a transaction commits, the accelerator 202 may continue to buffer stores to modified cache lines until the log is destroyed. Reads from modified cache lines during this period may be served from the pending store buffer to ensure consistency . In some cases, the accelerator 302 may forward load operations directly to SCM 303 to reduce latency. Once the undo log is destroyed, all mappings in the accelerator's SRAM may be cleared. Finally, regular operations may resume, with the cache lines being managed as usual by the system Figure 3 is a representation of an execution flow of a transaction backed by a redo log according to an example. Similar to Figure 2, the flow of Figure 3 depicts the interaction between three layers: the CPU (host) 301, the accelerator (ACC) 302, and the SCM (storage-class memory, i.e., persistent storage) 303.

[0061] The transaction may start when the host CPU 301 creates a transaction identifier tx and a redo log in its SRAM, which may be referenced throughout the transaction's lifecycle. The CPU 301 may perform a write operation to add entries to the redo log for objects modified within the transaction. Subsequently, the CPU 301 may issue a request to the accelerator 302 to persist the redo log to SCM 303.

[0062] The accelerator 302 may create a set in its SRAM containing the addresses of the cache lines modified by the transaction. This set may remain valid until the redo log is fully persisted in SCM 303. The accelerator 302 may asynchronously write the redo log to SCM 303 and acknowledge the host CPU 301 as soon as the log entry has been successfully written to the accelerator’s buffer, without waiting for the log to be fully persisted in SCM. The redo log entry may comprise the cache line address and the new value (as was assigned to the object in the transaction).

[0063] The CPU 301 may perform in-place updates to objects based on the redo log. These updates may initially reside in the CPU cache. When cache lines containing modified objects are evicted, the accelerator 302 may intercept the operations. To maintain consistency, the accelerator 302 may delay such store operations until the all redo log entries for the transaction are fully persisted in SCM 303. Pending stores may be buffered in the SRAM of the accelerator 302.

[0064] The CPU 301 may perform load operations on objects modified during the transaction. If the accelerator 302 detects that the load operation targets cache lines present in its SRAM set and a corresponding entry exists in the pending store buffer, it may serve the read from the buffer. Otherwise, the read may proceed to SCM 303 as usual. In some cases, the accelerator 302 may forward load operations directly to SCM 303 to reduce latency. This optimisation is also possible for operations involving the undo log. To commit the transaction, the CPU 301 may request an acknowledgment from the accelerator 302 once the redo log is fully persisted in SCM 303. The accelerator 302 may flush all modified cache lines to SCM 303, marking the redo log as irrelevant. The accelerator 302 may destroy the log asynchronously, allowing subsequent store operations to proceed. During this phase, the accelerator 302 may continue buffering store operations in its SRAM and serving loads from the pending store buffer until the log is fully destroyed. In case of an error, the redo log stored in SCM 303 may enable the system to recover and redo (roll forward) the transaction, similar to the scenario described above in relation to Figure 2.

[0065] Figure 4 is a representation of an execution flow of a transaction backed by a redo log according to another example. Akin to Figures 2 and 3, the flow once again depicts the interaction between three layers: the CPU (host) 401, the accelerator (ACC) 402, and the SCM (storage-class memory, i.e., persistent storage) 403. The transaction may begin when the host (in other words, the CPU) 401 creates a transaction identifier tx and a redo log in the SRAM. The redo log may include updates for all objects modified within the transaction. Once the log is created, the CPU 401 may issue a combined request to the accelerator 402 that serves as both a log communication call and a transaction commit instruction.

[0066] Upon receiving the request, the accelerator 402 may persist the redo log synchronously to SCM 403. As the accelerator 402 operates within the cache coherence domain of the host 401, the accelerator 402 is capable of managing cache line states. Once the redo log is fully created and persisted, the accelerator 402 may perform the updates to the objects, thereby invalidating any copies of the updated objects (cache lines) held in the host’s CPU caches, ensuring coherence of the modified cache lines across the entire cache coherence domain.

[0067] After persisting the log, the accelerator 402 may acknowledge the CPU 401 , indicating that the commit phase is complete. The accelerator 402 may then proceed to update the objects in SCM 403 based on the redo log entries. Advantageously, offloading of the object updates to the accelerator 402 can significantly reduce the overall transaction execution time, thereby reducing transaction latency.

[0068] Once all object updates are complete, the accelerator 402 may destroy the redo log asynchronously. During this phase, the system may continue servicing subsequent operations without delay, as the transaction's effects have already been committed to SCM 403. Importantly, by utilising this approach, the accelerator 402 can take on much of the workload, thereby minimising the processor’ s 401 involvement, resulting in a reduction of execution latency while maintaining consistency across the memory hierarchy.

[0069] Figure 5 is a schematic representation of an architecture of a transactional accelerator. The transactional accelerator 500 may be part of a larger system comprising a processor (a host) 550. In the example shown in Figure 5, the transactional accelerator 500 is located within a memory module (for example, a storage-class memory, SCM, which is an example of a persistent storage) 510, comprising multiple memory sub-modules (or chips) 515. However, the disclosure is not limited thereto, and the skilled person would appreciate that the transactional accelerator 500 may also be located within the host 550, or on an intermediate device (for example, on a CXL switch).

[0070] The transactional accelerator 500 may comprise a volatile memory 520 (for example, a static random-access memory, SRAM). The volatile memory 520 may comprise a mapping module 521, comprising a mapping of cache line addresses to old values, as well as a pending store buffer 522. The transactional accelerator 500 may be arranged to perform the operations described above in relation to Figures 1 to 4.

[0071] While various embodiments have been described and / or illustrated herein in the context of fully functional computing systems, one or more of these exemplary embodiments may be distributed as a program product in a variety of forms, regardless of the particular type of computer-readable-storage media used to actually carry out the distribution. The embodiments disclosed herein may also be implemented using software modules that perform certain tasks. These software modules may include script, batch, or other executable files that may be stored on a computer-readable storage medium or in a computing system. In some embodiments, these software modules may configure a computing system to perform one or more of the exemplary embodiments disclosed herein. In addition, one or more of the modules described herein may transform data, physical devices, and / or representations of physical devices from one form to another.

[0072] The preceding description has been provided to enable others skilled in the art to best utilize various aspects of the exemplary embodiments disclosed herein. This exemplary description is not intended to be exhaustive or to be limited to any precise form disclosed. Many modifications and variations are possible without departing from the spirit and scope of the instant disclosure. The embodiments disclosed herein should be considered in all respects illustrative and not restrictive. Reference should be made to the appended claims and their equivalents in determining the scope of the instant disclosure.

Claims

CLAIMS1. A method for accelerating transaction execution in a system comprising an accelerator for performing cache-coherent operations and a persistent storage, the method comprising: receiving, by a processor, a request to modify data stored in the persistent storage as part of a transaction (101); creating, by the processor or the accelerator, a transaction identifier associated with the request, and at least one persistent log entry for an object to be modified as part of the transaction, wherein a log entry is based on a type of log used (102); determining, by the accelerator, a set of addresses of cache lines in a memory of an accelerator, wherein the cache lines in the memory of the accelerator are cache lines to be modified as part of the transaction (103); receiving or retrieving, by the accelerator, data associated with the request from the CPU or persistent storage, and transferring the data to corresponding cache lines within the memory of the accelerator (104); performing, using the accelerator or the processor, the requested modification on the data in the memory of the accelerator, thereby generating multiple modified cache lines (105); buffering, by the accelerator, the multiple modified cache lines in a memory of the accelerator until the associated initial log entries for the objects to be modified have been written to the persistent storage (106); writing, by the accelerator, log entries to persistent storage, such that the old or new values, depending on the log type, are persisted before committing changes (107); writing, by the accelerator, the modified data from the memory of the accelerator to the corresponding locations in the persistent storage (108); removing, by the accelerator, the log entries and the corresponding data in the memory of the accelerator once the modified data has been persisted to the memory and the logs are no longer needed (109); allowing, by the accelerator, the CPU to proceed with subsequent operations upon acknowledgment of completion of required steps in log creation or data persistence (110).

2. The method of claim 1, wherein determining the set of addresses of cache lines in the memory of the accelerator and the corresponding persistent storage locations comprises calculating an offset based on a difference between a starting address of the memory of the accelerator and a starting address within the persistent storage.

3. The method of claim 2, wherein the calculated offset is applied by the accelerator to determine the corresponding persistent storage locations for each modified cache line in the memory of the accelerator.

4. The method of claim 3, comprising copying, by the accelerator, only the modified cache lines to the corresponding persistent storage locations based on the calculated offset.

5. The method of any one of claims 2 to 4, wherein determining the set of addresses of cache lines in the memory of the accelerator and the corresponding persistent storage locations comprises the use of a hash table stored in the memory of the accelerator to facilitate lookups of the corresponding persistent storage addresses.

6. The method of any one of claims 1 to 5, wherein the data associated with the request is organised within a tracking data structure within the memory of the accelerator, the tracking data structure being arranged to enable the accelerator to identify which cache lines within the memory of the accelerator have been written to during the requested modification.

7. The method of any one of claims 1 to 6, wherein removing, by the accelerator, the log entries and the corresponding data in the memory of the accelerator once the modified data has been persisted to the memory and the logs are no longer needed comprises asynchronously destroying, by the accelerator, log entries stored in the persistent storage after the modified data has been successfully persisted and confirmed as no longer needed.

8. The method of any one of claims 1 to 7, wherein allowing, by the accelerator, the CPU to proceed with subsequent operations upon acknowledgment of completion of required steps in log creation or data persistence comprises sending, by the accelerator to the CPU, an early acknowledgment indicating that the accelerator has initiated asynchronous creation of a log entry associated with the requested modification.

9. An apparatus for accelerating transaction execution in a system comprising an accelerator (500) for performing cache-coherent operations and a persistent storage (510), the apparatus comprising an accelerator (500) arranged to: receive a request to modify data stored in the persistent storage (510) as part of a transaction; create a transaction identifier associated with the request and generate an initial log entry in the persistent storage (510) for each object to be modified by the transaction; determine, using the accelerator, a set of addresses of cache lines in a volatile memory of the accelerator (500) and corresponding addresses in the persistent storage (510); transfer data associated with the request from the persistent storage (510) to the corresponding cache lines within the accelerator's volatile memory; perform the requested modification on the data in the volatile memory, resulting in multiple modified cache lines; buffer the modified cache lines in a memory of the accelerator (500) until the associated initial log entries have been written to the persistent storage (510); generate, for each modified object, a further log entry in the persistent storage (510), wherein each further log entry reflects the value of the modified data in the volatile memory; write the modified data from the volatile memory to the corresponding locations in the persistent storage (510); and remove each further log entry for a modified object once the modified data has been written to the persistent storage (510).

10. The apparatus of claim 9, wherein the accelerator is configured to determine the set of addresses of cache lines in the memory of the accelerator and the corresponding persistent storage locations by calculating an offset based on a difference between a starting address of the memory of the accelerator and a starting address within the persistent storage.

11. The apparatus of claim 10, wherein the accelerator is configured to apply the calculated offset to determine the corresponding persistent storage locations for each modified cache line in the memory of the accelerator.

12. The apparatus of claim 11, wherein the accelerator is configured to copy only the modified cache lines to the corresponding persistent storage locations based on the calculated offset.

13. The apparatus of any one of claims 9 to 12, wherein the accelerator is configured to use a hash table stored in the memory of the accelerator to facilitate lookups of the corresponding persistent storage addresses.

14. The apparatus of any one of claims 9 to 13, wherein the accelerator is configured to asynchronously destroy log entries stored in the persistent storage after the modified data has been successfully persisted and confirmed as no longer needed.

15. The apparatus of any one of claims 9 to 14, wherein the accelerator is configured to send, to the CPU, an early acknowledgment indicating that the accelerator has initiated asynchronous creation of a log entry associated with the requested modification.

Images