Fine-grained resource management for rollback memory operations

Abstract

Methods, systems, computing devices, and machine-readable media are disclosed in some examples, wherein the system maintains a list of resources available for each rollback session. In some examples, status data indicative of available memory is maintained. If a write occurs to a particular session and an amount of available memory for the session has been used, a flag is set in metadata of a memory location and the write is not mirrored. In this manner, the technical problem that one revocation log session uses too much memory and other revocation log sessions are prevented from properly operating is solved by a technical solution that sets resource limits for each revocation log session.

Description

[0001] Priority application

[0002] This application claims priority to U.S. Application No. 17 / 716,250, filed on April 8, 2022, which is incorporated herein by reference in its entirety.

[0003] Government Rights

[0004] This invention was made with U.S. Government support under Agreement No. DE-AC05-76RL01830 awarded by Pacific Northwest National Laboratory. The U.S. Government has certain rights in this invention. Technical Field

[0005] Embodiments relate to memory devices. Some embodiments relate to restoring to previous data values ​​stored in the memory device upon a suspension or failure of operation of the memory device or application. Some other embodiments relate to providing multiple different rollback sessions that can be individually controlled. Still other embodiments relate to managing resource allocation across those different sessions. Background Art

[0006] Memory devices used in computers or other electronic devices can be classified as volatile and non-volatile memory. Volatile memory requires power to maintain its data, and includes random access memory (RAM), dynamic random access memory (DRAM), or synchronous dynamic random access memory (SDRAM), etc. Non-volatile memory can retain stored data when not powered, and includes flash memory, read-only memory (ROM), electrically erasable programmable ROM (EEPROM), static RAM (SRAM), erasable programmable ROM (EPROM), resistance variable memory, phase change memory, storage class memory, resistance random access memory (RRAM) and magnetoresistive random access memory (MRAM), etc. Persistent memory is a type of non-volatile memory characterized as byte-addressable low-latency memory. Examples of persistent memory may include non-volatile dynamic in-line memory modules (NVDIMMs), phase change memory, storage class memory, and the like. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In the drawings, which are not necessarily drawn to scale, similar numbers in different views may describe similar components. Similar numbers with different letter suffixes may represent different instances of similar components. The drawings generally illustrate various embodiments discussed in this document by way of example and not by way of limitation.

[0008] Figure 1 An operating environment of a memory device according to some examples of the present disclosure is described.

[0009] Figure 2 A flowchart illustrating a method of initializing an undo log session according to some examples of the present disclosure.

[0010] Figure 3 Diagram illustrating metadata and physical storage according to some examples of the present disclosure.

[0011] Figure 4 The format of a memory region according to some examples of the present disclosure is described.

[0012] Figure 5 A flow chart illustrating a method of operating a system during an undo recording session according to some examples of the present disclosure.

[0013] Figure 6 A flowchart illustrating a method of submitting instructions according to some examples of the present disclosure.

[0014] Figure 7 A flow chart illustrating a method of handling an abort instruction or other failure to undo a recording session according to some examples of the present disclosure.

[0015] Figure 8 A segment recovery structure according to some examples of the present disclosure is described.

[0016] Fig. 9 A flow chart illustrating a method for determining whether there is sufficient memory to allocate a mirrored block according to some examples of the present disclosure.

[0017] Fig.10 A flow chart illustrating a method of preventing an undo log session from using too many resources according to some examples of the present disclosure.

[0018] Fig.11 is a block diagram illustrating an example of a machine upon which one or more embodiments may be implemented. DETAILED DESCRIPTION

[0019] The confluence of several factors, such as the increasing speed (and decreasing latency) of memory devices (storage class memory devices and other persistent memory devices) combined with their non-volatile nature; the increasing speed of computer buses, such as Peripheral Component Interconnect Express (PCIe); and other factors, has made such memory devices more directly usable by other components of a host computer system. For example, Compute Express Link (CXL) may allow the storage of a memory device to be shared across multiple components. For example, a storage class memory device may be used by a CPU in a manner similar to the way that a CPU uses RAM. CXL enables these uses over the PCIe physical and electrical interface with a new protocol that allows memory and cache coherency between components.

[0020] These and other use cases for persistent memory present new challenges for applications executing on these systems. For example, in the past, memory operations were completed in volatile RAM and then flushed to non-volatile memory upon completion. This provides a method of performing calculations in memory and saving the resulting values ​​only when such calculations succeed or otherwise meet defined criteria. The use of non-volatile storage means that intermediate values ​​can be stored to the non-volatile storage at any time. Thus, a power outage or other failure in an intermediate memory operation creates the possibility that the data stored in the storage device is in an invalid intermediate state. This state is difficult to detect and difficult to recover from without significant additional instructions and additional checks.

[0021] In response to these needs, a technology has been developed that allows an application to create an undo log session when a memory operation may need to be rolled back in the event of a crash or other failure. The undo log session begins with an application providing a list of one or more memory locations. The memory states of those locations are preserved until the application thread indicates that the undo log session is complete, and the memory modifications should be submitted or should be discarded. During the undo log session, a copy of the value is executed to a memory write to a specific memory location in the list of one or more memory locations provided by the application and the original value is retained. If the undo log session is submitted, the copy becomes the correct value and can then be used to replace the original, or the value stored in the copy is copied to the original. If the undo log session is abandoned, the copy is not retained, and the value returns to the original.

[0022] The memory blocks allocated for the undo log session can be withdrawn after the operation is submitted or aborted. The amount of memory allocated for the undo log session may be related to the amount of memory modified rather than the number of modifications. Therefore, a single block that is modified, regardless of the number of times it is modified, requires a single block to save the original memory value and a block to save the current value. Therefore, the disclosed method has a relatively low resource overhead. This is in contrast to some solutions that may record each modification, which may quickly use up a large amount of memory resources. In addition, the time used to start and complete the operation is proportional to the amount of memory used by the operation. In some instances, the memory used for the purpose of undo log is allocated to the process rather than from the whole system pool to prevent unintentional or intentional denial of service attacks. Therefore, the present disclosure solves the technical problem of data integrity of a persistent memory device by utilizing a technical solution for undo log sessions, which saves the memory state before the undo log session and uses metadata to control the undo log session.

[0023] In some instances, it may be desirable to have finer-grained control over what values ​​are committed and what values ​​are rolled back. For example, in order to have multiple different sessions that can be committed or undone independently. In some instances, the system may provide multiple undo log sessions that may be performed simultaneously. Each undo log session may correspond to one or more memory locations of different groups. The operation to undo or commit the first log session is independent of the second log session. That is, if the first log session is rolled back, the second log session may be committed. Because the memory resources for storing the changed values ​​within the undo log session may be limited, problems may arise when an undo log session uses up more than its fair share of resources. This may cause failures in other undo log sessions. This may be a greater problem for multi-process and multi-processor environments in which memory serves many different processes executed on different processors.

[0024] In some examples, methods, systems, computing devices, and machine-readable media are disclosed, wherein the system maintains a list of resources available for each rollback session. In some examples, state data indicating available memory is maintained. If a write occurs for a particular session that triggers allocation of a mirrored block and the amount of available memory for the session has been used, an error flag is set in the metadata for the memory location, the mirrored block is not allocated, and the original block is used to service the write. In this way, the technical problem of one undo log session using too much memory and preventing other undo log sessions from functioning properly is solved by a technical solution that sets resource limits for each undo log session.

[0025] Figure 1 The operating environment of the memory device 120 according to some examples of the present disclosure is described. The host system 110 may include, contain components of a computing device, or be integrated into a computing device, such as Fig.11 In some examples, host system 110 may include processor 116 (which may be Fig.11 102). Processor 116 may include one or more caches, such as L1, L2, and / or L3 caches. Operating system 114 may execute on processor 116 and may provide one or more application programming interfaces (APIs) for applications, such as application 112, to interact with the system's hardware (e.g., Fig.11 The application 112 may use the hardware and resources provided by the operating system 114 to perform one or more functionalities. The interface components 118 and 126 may be or manage the physical interface 119 and may include one or more software and / or protocol implementations. Example interface components may implement a PCIe interface, a Universal Serial Bus interface, a CXL interface, and the like (e.g., the interface components 118 and 126 and the physical interface 119 may be, for example, Fig.11 An example of an interconnect link 1108 of an interconnect).

[0026] The memory device 120 may include a memory 122, such as a NAND memory device, a phase change memory, a random access memory (RAM), and the like. The memory 122 may be an example of a main memory 1104, a static memory 1106, or a drive unit 1116. The memory controller 124 may be or include one or more processing units that can manage the memory 122, such as Fig.11 The processor 1102 of the embodiment of the present invention can be a memory controller 124. The memory controller 124 can have a volatile storage device for storing data and instructions. Fig.11 104. As an example, the memory controller 124 may include one or more logical-to-physical mapping tables that convert logical addresses to physical addresses on the memory 122. Other examples may include other management functions with respect to the memory 122, such as obsolete item collection, error correction, refresh control, and the like. As described, the host system 110 may maintain cache and / or memory coherency between the host system 110 and the memory device 120.

[0027] In some examples, all of the memory 122 in the memory device may be used to undo the logging session. In other examples, only certain memory regions that are marked as eligible may be used to undo the logging session. Regions that are eligible for undo logging sessions may be marked using metadata, flags, or the like. Regions may be contiguous ranges of physical addresses. Regions may be assigned to an application or a group of applications during their execution. For example, one or more regions may be assigned to Figure 1 112. In some examples, multiple individual memory areas may be combined to form a larger memory pool. The memory area may then be subdivided into one or more extents. An extent may be a contiguous range of physical addresses within an area. Segments may be combined in lists and may have gaps between them. Segments may be software-requested memory objects that may be used during operations utilizing an undo log session. In some examples, segments may be aligned on 64-byte (B) boundaries. Each undo log session may have an associated list of one or more segments that are part of that session. In some examples, a segment may belong to only one session at a time.

[0028] An application (e.g., such as application 112) may create an undo logging session. For example, the application may call a function provided by an operating system (e.g., operating system 114 and / or provided by memory controller 124). One example function may be in the form of UndoLogging_start(segment vector). This function may return an operation identifier (undoID), which may be a unique session identifier that identifies the undo log session. When the UndoLogging_start function is called, the system may verify that each of the segments passed in with the function is within a region where the undo logging feature is enabled (e.g., via a flag or other attribute associated with the memory region). Additionally, for each segment in the newly created undo log session, the system may flush host cache lines that are in an exclusive or modified state back to the memory device. For example, a CXL device may allow a processor (e.g., processor 116) to take control of one or more memory locations of a memory (e.g., memory 122). In this state, the values ​​stored in the memory device may not be up to date (e.g., the cached values ​​may be more recent). By flushing the cache, all updates made by the processor may be flushed back to the memory. Once complete, flushing the cache will establish a consistent starting snapshot for recovery operations (if necessary). In addition, the system can initialize the bit field of the segment that tracks the state of each memory line. Finally, the system can write the segment list to persistent storage for crash cleanup.

[0029] Figure 2 A flow chart illustrating a method 200 for initializing an undo log session according to some examples of the present disclosure. The method 200 may be performed by an operating system of a host, a controller of a memory device, a portion may be performed by the host and other portions may be performed by a controller of the memory device, or the like. At operation 210, the system may verify the segments requested for the undo log session. For example, a function call to an API called by an application executing on the host may be used to initiate the method 200. The function call may include or otherwise specify one or more segments. The segments may be verified to ensure that they are within a memory area configured to support undo log sessions and to ensure that they are not part of an existing session. At operation 215, if one or more of the segments are invalid, the system returns an error. If the segments are valid, then at operation 220, an undo log session identifier is assigned. This identifier may be a unique identifier. The identifier may be unique to the entire system (including the host and other memory devices) or may be unique to the memory device.

[0030] At operation 225, for each memory row (e.g., CXL device) associated with the segment passed in with the function call currently indicated as being in the exclusive or modified state, the memory row is flushed. In some examples, such flushing may be accomplished using CXL coherency commands or host software instructions. This operation ensures that the memory device has updated and valid memory when the withdraw command is initiated.

[0031] At operation 230, tracking structures may be initialized. These tracking structures include metadata and memory block points and will be related to Figure 3 and 4 A more detailed description is given in Figure 3 Initialization of these tracking structures is described in more detail in . At operation 235, recovery structures may be initialized. These structures are used to undo all currently pending undo log sessions that have not been committed in the event of a power or other failure. Figure 8 These structures are described in more detail.

[0032] At operation 240, the call may return an undo log session identifier to the caller (e.g., an application). The undo log session identifier may be used to reference this particular operation in subsequent function calls or commands. For example, the system may allow an application to add segments to an operation by supplying additional segments and the undo log session identifier. In these instances, the system may validate the additional segments, flush the cache lines of the added segments, initialize the tracking structures of the added segments, and add the segments to the recovery structures as described for the creation of an undo log session.

[0033] In some instances, except Figure 2 In addition to the checks shown in , the system may also check to ensure that the segment has not become part of a different undo log session. In some examples, each segment may be limited to a single undo log session. It should be noted that during operation 230, the metadata of each segment in the session may be updated to reflect that the segment participated in the session (e.g., by setting the appropriate session id). In some examples, if different memory locations corresponding to the metadata structure have been involved in different undo log sessions (because each metadata structure serves multiple memory locations), then the metadata may be updated to reflect that the memory tracked by the metadata structure involves multiple sessions.

[0034] As described, the system uses various tracking structures and initializes them during the creation of the undo log session (e.g. Figure 2 Operation 230). For example, each memory row of a segment involved in an undo log session may have 5 bits of associated metadata. For example:

[0035] - T (Trace) bit—Indicates that the memory row is currently participating in an undo log session.

[0036] - W (Writable) bit - tracks whether the memory line is in the writable state in the host cache.

[0037] F (first written) bit—tracks whether the row has been written since the undo log session started.

[0038] S (Select) bit - records the starting (original) location of the row at the start of the operation. If a mirror block (block B) was previously assigned to a data block (block A), then after the operation is complete, the F bit can be cleared and the original memory row can be left in its original location to minimize data movement. The S bit identifies where the original "backup" copy of the data resides.

[0039] And cache line writes are redirected to the relative block.

[0040] E (Error) bit - records whether the block pool has been exhausted when writing a row. When this bit is set, the read must return an error to the requester (e.g., return a CXL poison indication).

[0041] In addition, as described, during the undo log session, each logical memory block may have two associated physical memory blocks. One physical block saves the original value at the start of the undo log session and uses the physical block if the undo log session is rolled back in the case of a failure or explicit operation abort (e.g., abort by a function call). The other block is initialized to the value of the first physical block and stores the changes made to the memory during the undo log session. This block stores the value used in the case of submitting the undo log session. As described above, the selection bit of the metadata indicates which block is the original value and which block is the value updated by the memory operation during the undo log session. This allows for more efficient submission or rollback because the system only flips the bit to indicate which block is a valid value. That is, if the first block stores the initial state and the second block stores the state as the result of the memory operation performed while the undo log session is running-if the undo log session is submitted, the selection bit will point to the second block. On the other hand, if the application performs a rollback of the undo log session, the selection bit will point to the first block. Subsequent operations (whether or not in the undo log session) will be performed on the block indicated by the selection bit.

[0042] The following table illustrates a sequence of memory rows and example values ​​for each of the TWFSE bits that are set in response to various example memory operations. Note that whether the select bit is 1 or 0 depends on the outcome of the previous undo log session. If this is the first undo log session for the block that this memory row is a part of, then this may be initialized to a default value (0 or 1).

[0043]

[0044] *Note that on the first write, if the system does not have enough blocks to allocate the second block, then TWFSE will set the error bit (E) to 1.

[0045] Figure 3 Diagram 300 illustrating metadata 310 and physical storage 340 according to some examples of the present disclosure. Metadata data structures 315, 317, and 319 store state information for undo log sessions. Figure 3 In the example of , each of metadata data structures 315, 317, and 319 stores metadata information for four 512B memory blocks. Included in metadata data structures 315, 317, and 319 is a TWFSE metadata field. In some examples, a separate TWFSE metadata field may be stored for each memory row of each block. If the memory row is 64B and the block is 512B, then there are eight TWFSE metadata fields per block. As described, in Figure 3 In the example of , each metadata data structure 315, 317, and 319 stores metadata for 4 blocks. Therefore, there are 32 TWFSE fields (512B per block / 64B per row = 8*4 blocks per metadata structure) and 8 block address pointers (2 block address pointers per block * 4 blocks). Each pair of block address pointers corresponds to a block. Therefore, the first memory block may have two address pointers pointing to the physical addresses of one or more memory blocks in the physical memory 340. For example, the physical addresses of blocks 325 and 330. Blocks 325 and 330 form a block pair, in which one block can be used to store values ​​before the undo log session and the other block can store values ​​resulting from memory operations performed during the undo log session. As described, the selection bit in the TWFSE field can determine which of the blocks is used to store values ​​before the undo log operation and which block can store values ​​resulting from memory operations performed during the undo log session. Figure 4 The format of memory region 400 is illustrated. The lower address range of region 420 can be used as memory blocks and the upper region 410 can be used for metadata.

[0046] As previously described, the multi-session flag 350 in the metadata structure may indicate whether the memory rows corresponding to the metadata data structure are related to the same session, or whether one or more memory rows are in one session and one or more other memory rows are in different sessions. If the multi-session flag 350 is false, the session ID field 355 stores the undo log session id of one or more memory locations that are part of the session served by the metadata structure. The session id may be an index into the session list 375. The session list at the session index may store a mirror row availability counter 380. This field tracks the amount of allocated mirror blocks available for that particular session. This value may be decremented each time a mirror block is allocated. If this value is zero, additional attempts to allocate mirror blocks will fail and the "E" bit of the TWFSE metadata will be set to indicate an error. When a mirror block is deallocated, the value of the mirror row availability counter may be incremented.

[0047] If the multi-session flag 350 is set, this indicates that different memory lines tracked by the metadata structure may be in different sessions. In this case, the session id field 355 may be an index to or point to a multi-session list. Each entry in the list has a memory row mask with 32 bits and a session id. A next pointer 385 may point to the next entry in the list. The session id of each row serves as an index to the session list 375, which gives a mirror row availability counter 380. The memory row mask 365 has a single bit for each of the 32 memory lines served by the metadata structure (e.g., metadata data structure 315, 317, or 319). One value of the bit (e.g., '1') indicates that the memory line is part of the undo log session indicated by session id 370. One value of the bit (e.g., '0') indicates that the memory line is not part of the undo log session indicated by session id 370. In some examples, there are as many memory row mask 365 and session id 370 pairs in each multi-session list entry as the maximum number of simultaneous sessions supported by the metadata structure. In other examples, there are a fixed number of memory row mask 365 and session id 370 pairs in each multi-session list entry. Since the metadata structure may have rows that participate in more than the fixed number of simultaneous sessions, the next pointer 385 may then point to the next multi-session list entry that includes sets of memory row masks and session ids for the same metadata structure.

[0048] When a new undo recording session is started at operation 230, the system may iterate through the metadata data structures (e.g., 315, 317, and 319) of each memory location within the new undo recording session. For each particular metadata state structure:

[0049] aIf there is currently no active undo log session (ie, all T flags are clear in the TWFSE field of the specific metadata structure), then multi-session is set to false and the session ID is assigned the appropriate session list entry index.

[0050] b If at least one T flag bit is set in the TWFSE field of a particular metadata structure, the multi-session bit is false, and the new session ID matches an existing session ID, then the multi-session bit and the session ID field are not modified (the T flag is set for the new segment).

[0051] c If at least one T flag bit is set in the TWFSE field of the particular metadata structure, the multi-session bit is false, and the new session ID does not match the session ID field in the particular metadata structure, then a new multi-session list entry is allocated. The existing session information is entered into the multi-session list entry. The memory row mask is set to match the meta-status T flag, and the session ID is assigned the session ID within the particular metadata structure. The multi-session bit is set to true and the session ID field is set to the multi-session entry index. The new sector information is entered into the multi-session entry using the next paired field (memory row mask and session ID).

[0052] d If the multi-session bit is true, the system determines whether the session ID already exists in the multi-session list. In this case, bits are set in the mask paired with the session ID to indicate which memory rows served by the metadata are participating in that session.

[0053] eIf the multi-session bit is true, and the system determines that the session ID does not exist in the multi-session list, then the session information is entered into the multi-session list. If an existing multi-session entry does not have a memory row mask / session ID entry, then a new multi-session entry is allocated and linked to the first entry using the next field. It should be noted that a multi-session list entry with the memory row mask set to zero implies an unused entry.

[0054] Figure 5 Flowchart illustrating a method 500 of operating a system during an undo recording session according to some examples of the present disclosure. In some examples, Figure 5The operation may be performed by a memory device, an operating system of a host, an application on the host, a combination of the foregoing, or the like. At operation 510, the system receives an operation for a memory row of a segment. At operation 515, the system determines whether the segment is part of an undo log session. For example, the system may determine whether the "tracking" bit of the TWFSE metadata is set for one or more memory rows of the segment. If not, the system processes the request normally. If the segment is part of an active undo log session, then at operation 520, it is determined what memory operation is requested. If the operation is a memory read—for example, the host is accessing the row for a write, then at operation 555, the system may set the writeable bit in the TWFSE field of the metadata.

[0055] If the row is evicted from the host without changes, then at operation 550, the writeable bit is cleared. If the row is written back by the host, then at operation 525, it is determined whether the write is the first write to the row of memory for the undo log session. If the write is the first write, then at operation 535, the system determines whether there is enough memory to allocate a second block to save the changes made during the undo log session. Fig. 9 Detailed description of example operations that can be used to determine if there is enough memory to allocate. If not, then at operation 540, the system can indicate an error. For example, the system can set an error bit in the metadata and / or can issue an exception or other signal. If there are enough blocks, then at operation 545, the system can allocate another memory block, initialize the pointer in the metadata to point to the second block, set the first write bit, and flip the select bit so that the new operation is performed in the newly allocated block. At operation 530, the data is written to the block in the block pair indicated by the select bit.

[0056] Figure 6 Flowchart illustrating a method 600 of submitting instructions according to some examples of the present disclosure. In some examples, Figure 6 The operation may be performed by a memory device, an operating system of a host, an application on the host, a combination of the foregoing, or the like. The commit instruction terminates the undo log session, and the results of the memory operations performed during the undo log session are considered to be the appropriate values ​​of the memory block and are committed. The backup values ​​stored in the matched memory block may be discarded and not used. In other examples, the backup values ​​may be recorded in a log file. At operation 610, a commit instruction is received. The commit instruction may be a function call, such as UndoLogging_commit(SessionID). The calling entity passes in the undo log session identifier.

[0057] At operation 615, the memory line in the exclusive state for each segment associated with the undo log session whose identifier is specified is flushed back to memory (e.g., determined using the writable bit of the TWFSE metadata and, if the multi-session bit is set, the memory line mask). At operation 620, if the flush results in the first write to the memory line (e.g., if the memory line was not previously changed before the flush at operation 615), then at operation 635, the system determines whether there are enough memory blocks to allocate the new memory block. Fig. 9 Detailed description of the operation used to determine whether there is enough memory to allocate. If there are not enough memory blocks, then an error is returned at operation 645. If there are enough memory blocks, then at operation 640, the first write bit is set, memory is allocated, and the selection bit is flipped. At operation 625, data is written to the block in the block pair indicated by the selection bit. At operation 630, the system can remove the undo log session identifier and remove the segment metadata from the persistent memory. Subsequent writes to the memory row will utilize the block in the block pair pointed to by the selection bit. In some instances, another block that the selection bit does not point to can be deallocated for use in other undo processes.

[0058] In some examples, at operation 635, the multi-session bit of the metadata may be checked. If not set, then at operation 640, the mirror row availability counter may be reset to a default value. If the multi-session bit is set at operation 635, then at 645, a multi-session list is accessed (e.g., using the session id in the metadata to find the multi-session list), and at operation 650, the mask for the corresponding session id is cleared. At operation 655, the mirror row availability counter is reset to a default value. At operation 660, it is determined whether only one session remains for the memory row associated with a particular metadata structure (e.g., metadata data structures 315, 317, and 319). If so, then at operation 665, the multi-session bit is cleared in the metadata structure, the multi-session list is removed or set to a default value, and the session id is updated to the value of the last remaining session.

[0059] Operations 635 to 665 assume that once the session is committed, the session ends. In other examples, the session may persist across multiple intervals. That is, after the interval ends, the log session may write the values ​​of any changed memory rows to a particular log structure. In these examples, once the write is committed to the log, the mirror row is then deallocated and the availability counter at operations 640 and 655 is then incremented. Then, when the session terminates, the session is simply cleared using operations 650, 660, and 665.

[0060] Figure 7Flowchart illustrating a method 700 of handling abort instructions or other failures to undo a recording session according to some examples of the present disclosure. In some examples, Figure 7 The operation may be performed by a memory device, an operating system of a host, an application on the host, a combination of the foregoing, or the like. At operation 710, the system may receive an abort instruction or otherwise detect a fault. In some instances, aborting an undo log session may be initiated by a call to UndoLogging_abort (SessionID) or detection of a fault (e.g., a reset, power failure, or the like). At operation 715, the system may flush the memory rows in an exclusive state in each segment involved in the undo log session back to the memory (e.g., the memory rows may be determined using the writable bits of the TWFSE metadata). This may ensure that any cached writes caused by operations performed during the undo log session will not change the data after the undo log session is aborted. At operation 720, the system may restore the original values ​​in each segment by restoring the backup values. In some instances, this may include copying the values ​​in the blocks in the block pair that retains the original state to another block. In yet other instances, this may include flipping the selection bits. Subsequent memory accesses may be written to the memory block indicated by the selection bits. At operation 730 , the system may remove the undo log session by releasing the identifier and removing the segment metadata from persistent storage.

[0061] In some examples, at operation 735, the multi-session bit of the metadata may be checked. If not set, then at operation 740, the mirror row availability counter may be reset to a default value. If the multi-session bit is set at operation 735, then at operation 745, a multi-session list is accessed (e.g., the multi-session list is found using the session id in the metadata), and at operation 750, a mask for the corresponding session id is cleared. At operation 755, the mirror row availability counter is reset to a default value. At operation 760, it is determined whether only one session remains for the memory row associated with a particular metadata structure (e.g., metadata data structures 315, 317, and 319). If so, then at operation 765, the multi-session bit is cleared in the metadata structure, and the session id is updated to the value of the last remaining session.

[0062] Operations 735 to 765 assume that once the session is committed, the session ends. In other examples, the session may continue across multiple intervals. That is, after the interval ends, the log session may write the values ​​of any changed memory rows to a specific log structure. In these examples, once the write is committed to the log, the mirror row is then deallocated and the availability counters at operations 740 and 755 are then decremented. Then, when the session terminates, the session is simply cleared using operations 750, 760, and 765.

[0063] As described, if the session runs out of space to allocate a block on the first write, the application is notified using an interrupt, a poison bit in the CXL response packet, or a memory map status flag. The application can then decide what action to take. Example actions may include allocating more space, ending the operation, aborting the operation, or the like. In some examples, memory operations may be performed on the original memory blocks rather than the mirrored blocks.

[0064] To survive a power outage, a list of segments associated with an undo log ID may be saved in persistent storage. In some instances, various data structures may be used to store this mapping. For example, Figure 8 A segment recovery structure 800 according to some examples of the present disclosure is illustrated. The structure has two substructures: an ExtentHead 810 data structure and an ExtentList 820 data structure. The ExtentHead 810 structure is a list of active operations that need to be recovered, which associates a sessionID with a pointer to the header of the ExtentList 820 structure. The ExtentList 820 is a list of segments (containing a start address and an end address) in the active operations of a particular undo log session. For efficiency, the 4B session id and 4B ExtentHead pointer fields can be packed into 8B, allowing atomic swaps to simplify list maintenance. For 37-bit address offsets for ExtentStart and ExtentEnd (maximum 128GB zone size), a 64B cache line sized metadata block can store six complete segments along with a "next block" pointer called ExtentNext. An ExtentStart of all 1s may not be used, and an ExtentNext of all 1s can mark the end of the list.

[0065] Fig. 9 A flow chart illustrating a method 900 for determining whether there is sufficient memory to allocate a mirror block according to some examples of the present disclosure. In some examples, method 900 may be an example of operations 535 and 635. Method 900 may be called when a new mirror block is to be allocated to a particular memory location. At operation 910, a determination is made as to whether a multi-session field in metadata corresponding to the particular memory location is set. If the multi-session field is set, then at operation 915, a multi-session list is traversed to find a session corresponding to the particular memory location. This is accomplished by traversing each memory row mask until a bit position of the mask corresponding to the particular memory location indicates that the particular memory location is participating in an undo log session. Once a memory row mask field is found in which a corresponding bit position is set to indicate that the particular memory location is part of an undo log session, the corresponding session id of the memory row mask is read.

[0066] Once the session id is obtained, or if the multi-session field is not set at operation 910 (and the session id can be obtained directly from the metadata), the session id is used to access a resource availability counter (e.g., a mirror row availability count) in the session list at operation 920. If the resource availability counter is zero at operation 925, an error bit is set or some other error is generated for the metadata corresponding to a particular memory location (e.g., a memory row) at operation 940. If the resource availability counter is not zero, then at operation 930, the resource availability counter is decremented.

[0067] At operation 935, if the resource availability counter is zero after it is decremented, or if it is otherwise equal to some unspecified number (e.g., one, two, three, or some other warning threshold), then the system can warn the process that initiated the undo log session that the session memory is almost exhausted at operation 940. This process can allocate additional memory, stop the undo log session, or take other action.

[0068] Fig.10 Flowchart illustrating a method 1000 of preventing an undo log session from using too many resources according to some examples of the present disclosure. At operation 1010, a system may receive an indication of the start of an undo log session. In some examples, the start indication may be a message from an application on a host processor. The session may be associated with one or more memory locations (e.g., segments). The indication may provide a list of segments involved in the session. At operation 1015, a memory device may receive a write request for a memory location involved in the session—e.g., a location within one or more of the segments marked in the session for undo logging. In some examples, a first memory location may not have been written to during the undo log session, and therefore would trigger allocation of a mirror block.

[0069] At operation 1020, the system can identify resource counters for the session. For example, metadata for the memory location (e.g., metadata data structure 315, 317, or 319) can be located and a multi-session field identified. If the multi-session field is set to a value indicating that the memory location served by that metadata is not currently part of multiple sessions, the session id is determined using the value of the session id field from the metadata. The session id is then used as an index into a session list (e.g., session list 375) to determine a resource counter (e.g., mirror row availability counter 380).

[0070] On the other hand, if the multi-session field is set to a value indicating that the memory location served by that metadata is currently part of multiple sessions (e.g., one memory location is part of a first session and a second memory location is part of a second session), then the session id field can be read and used as an index or pointer to a multi-session list structure. The multi-session list structure can be a set of memory row masks and corresponding session id pairs. The memory row mask can identify the memory location involved in the corresponding session id. The system can use the memory row mask to locate the pair corresponding to the write request from operation 1015 and then identify the session id value corresponding to that memory location. The session id is then used as an index into a session list (e.g., session list 375) to determine a resource counter (e.g., mirror row availability counter 380).

[0071] At operation 1025, using the resource counter obtained in operation 1020, it is determined whether there are remaining session resources. For example, if the resource count is zero, then there may be no remaining additional resources. If there are no remaining session resources, then at operation 1030, an error bit is set in the TWFSE structure in the metadata corresponding to the memory location (which is to be written to the metadata (e.g., metadata in metadata data structure 315, 317, or 319)), and at operation 1035, the original block (rather than the allocated mirror block) can be used to service the write request. If there are additional resources, then at operation 1040, the resource counter can be decremented to reflect the allocation of the mirror block. At operation 1045, the mirror block can be allocated. At operation 1050, the TWFSE in the metadata structure can be updated to reflect the allocation of the mirror block. At operation 1055, the mirror block allocated at operation 1045 can be used to service the write request.

[0072] As described, the above concepts provide a way to limit the memory resource usage of a single undo log session to a predetermined amount. This is achieved by utilizing a small list of resources available per undo log session. Existing methods for providing rollback functionality use one 64B meta-state memory row for every 32 memory rows. There are several fields within the meta-state. In some instances, the present disclosure adds two additional fields (a multi-session bit and a session ID field) to the meta-state row. In addition, two structures are defined: a list of per-session available resource counters and a multi-session list. The per-session available resource counter list is used to determine whether additional resources are available when writing back a memory row from a host processor and need to be mirrored for possible future rollbacks. If the available resource counter is zero, the writeback is not mirrored and the meta-state error bit is set for the memory row.

[0073] The present disclosure provides resource monitoring as resources are consumed, thereby enforcing accurate fine-grained resource limits. The defined mechanism requires minimal hardware and can be executed without extending the write-back operation time. Previously identified mechanisms require performing an associative search across all active rollback segments, resulting in excessive cost of hardware resources to implement the search or excessive latency to perform the search.

[0074] As described, the present disclosure defines a hardware-based data structure that maintains a count of available resources per active rollback session. The metadata data structure (e.g., 315, 317, 319) stores a certain number of memory locations (in Figure 3 The overwritten memory rows may be in the same active undo log session segment, in different segments of the same undo log session or different sessions. In the event that a single session is active within the overwritten memory locations of the same metadata structure, then the multi-session bit may be set to false and the session ID field is assigned to the associated session list entry of the active rollback session. If multiple sessions are active within the metadata structure, then the multi-session bit may be set to true and the session ID field is set to the multi-session list entry. The multi-session list entry contains information for associating one or more memory locations with a session ID. The multi-session list contains several pairs of memory location masks and session IDs. The memory row mask indicates which overwritten memory locations are associated with the paired session IDs. The session ID specifies which entry in the session list represents the available resource counter for the session.

[0075] In some examples, when the rollback session segment is removed from the meta-state line, then if a multi-session list is being used, the list entry mask is set to zero. When a writeback occurs that requires a mirror block and the mirror line available count is zero, then the E flag is set and the writeback is not mirrored. In some examples, the new structure, multi-session list, and session list do not need to be stored in persistent storage. If the memory module is offline, then all active rollback sessions will be aborted (rolled back), at which point the old resource counters are of no value.

[0076] Fig.11A block diagram illustrating an example machine 1100 on which any one or more techniques (e.g., methodologies) discussed herein may be performed. In alternative embodiments, the machine 1100 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine 1100 may operate as a server machine, a client machine, or both in a server-client network environment. In an example, the machine 1100 may act as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. The machine 1100 may be in the form of a memory device, a host device (e.g., a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile phone, a smart phone, a network appliance, a network router, a switch, or a bridge), or any machine capable of executing instructions (sequentially or otherwise) specifying an action to be taken by that machine. Further, while a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies (e.g., cloud computing, Software as a Service (SaaS), other computer cluster configurations) discussed herein. Fig.11 The components are exemplary and fewer or additional components may be present in a memory device, a host device, or the like.

[0077] As described herein, an example may include or may operate on one or more logical units, components, or mechanisms (hereinafter "components"). A component is a tangible entity (e.g., hardware) that is capable of performing a specified operation and may be configured or arranged in a certain manner. In an example, a circuit may be arranged as a component in a specified manner (e.g., internally or relative to an external entity such as other circuits). In an example, all or part of one or more computer systems (e.g., stand-alone, client, or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application portions, or applications) as a component to perform a specified operation. In an example, the software may reside on a machine-readable medium. In an example, the software, when executed by the underlying hardware of the component, causes the hardware to perform the specified operation of the component.

[0078] Thus, the term "component" should be understood to encompass a tangible entity, i.e., an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., temporarily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operations described herein. Considering instances where components are temporarily configured, each of the components need not be instantiated at all times. For example, where a component comprises a general-purpose hardware processor configured using software, the general-purpose hardware processor may be configured as corresponding different components at different times. The software may configure the hardware processor accordingly, for example, to constitute a particular module at one time and to constitute different components at different times.

[0079] The machine (e.g., computer system) 1100 may include one or more hardware processors, such as processor 1102. Processor 1102 may be a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof. The machine 1100 may include a main memory 1104 and a static memory 1106, some or all of which may communicate with each other via an interconnection link (e.g., a bus) 1108. An example of the main memory 1104 may include synchronous dynamic random access memory (SDRAM), such as a double data rate memory, such as DDR4 or DDR5. The interconnection link 1108 may be one or more different types of interconnection links, such that one or more components may be connected using a first type of interconnection link and one or more components may be connected using a second type of interconnection link. Example interconnection links may include a memory bus, a peripheral component interconnect (PCI), a peripheral component interconnect express (PCIe) bus, a universal serial bus (USB), or the like.

[0080] The machine 1100 may further include a display unit 1110, an alphanumeric input device 1112 (e.g., a keyboard), and a user interface (UI) navigation device 1114 (e.g., a mouse). In an example, the display unit 1110, the input device 1112, and the UI navigation device 1114 may be a touch screen display. The machine 1100 may additionally include a storage device (e.g., a drive unit) 1116, a signal generating device 1118 (e.g., a speaker), a network interface device 1120, and one or more sensors 1121, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors. The machine 1100 may include an output controller 1128, such as a serial (e.g., universal serial bus (USB)), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate with or control one or more peripheral devices (e.g., printers, card readers, etc.).

[0081] The storage device 1116 may include a machine-readable medium 1122 having stored thereon one or more sets of data structures or instructions 1124 (e.g., software) embodying or utilized by any one or more techniques or functionality described herein. The instructions 1124 may also reside, completely or at least partially, within the main memory 1104, static memory 1106, or hardware processor 1102 during execution by the machine 1100. In an example, one or any combination of the hardware processor 1102, the main memory 1104, the static memory 1106, or the storage device 1116 may constitute a machine-readable medium.

[0082] Although machine-readable medium 1122 is illustrated as a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) configured to store one or more instructions 1124.

[0083] The term "machine-readable medium" may include any medium capable of storing, encoding, or carrying instructions for execution by the machine 1100 and causing the machine 1100 to perform any one or more techniques of the present disclosure, or capable of storing, encoding, or carrying data structures used by or associated with such instructions. Non-limiting machine-readable medium examples may include solid-state memory and optical and magnetic media. Specific examples of machine-readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; random access memory (RAM); solid-state drives (SSD); and CD-ROM and DVD-ROM optical disks. In some examples, machine-readable media may include non-transitory machine-readable media. In some examples, machine-readable media may include machine-readable media that is not a transitory propagation signal.

[0084] The instructions 1124 may be further transmitted or received via the network interface device 1120 using a transmission medium over a communication network 1126. The machine 1100 may communicate with one or more other machines by wire or wireless communication using any of a number of transmission protocols, such as frame relay, Internet Protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc. Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), a mobile telephone network (e.g., a cellular network), a plain old telephone (POTS) network, and a wireless data network, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards (known as IEEE 802.11 family of standards). ), IEEE 802.15.4 family of standards, 5G New Radio (NR) family of standards, Long Term Evolution (LTE) family of standards, Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, and the like. In an example, the network interface device 1120 may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas to connect to the communication network 1126. In an example, the network interface device 1120 may include multiple antennas to use at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) technology for wireless communication. In some examples, the network interface device 1120 may use multi-user MIMO technology for wireless communication.

[0085] Other notes and examples

[0086] Example 1 is a method comprising: receiving an indication of the start of an undo log session from an application, the indication of the start of the undo log session identifying a set of physical memory locations of a memory device; receiving a write request for a first physical memory location of the memory device, the first physical memory location being within the set of physical memory locations of the memory device, the first physical memory location not being written to during the undo log session; in response to the write request: identifying a resource counter based on a multi-session bit field and a session id field of a metadata data structure corresponding to the first physical memory location; determining that the undo log session has remaining memory resources based on the resource counter; in response to determining that the undo log session has remaining resources: reducing the resource counter; allocating a second physical memory location of the memory device; and updating at least one bit of the metadata data structure from indicating that the memory request is to be serviced at the first physical memory location to indicating that the memory request is to be serviced at the second physical memory location; and servicing the write request using the second physical memory location.

[0087] In Example 2, the subject matter of Example 1 includes wherein the memory device is a persistent memory device connected to a host using an interface configured for a Compute Express Link (CXL) protocol.

[0088] In Example 3, the subject matter described in Examples 1 to 2 includes, wherein identifying the resource counter based on the multi-session bit field and the session id field of the metadata data structure corresponding to the first physical memory location includes: determining that the multi-session bit field is set to a value indicating that no multi-session undo log is active for any memory location corresponding to the metadata data structure; in response to determining that the multi-session bit field is set to a value indicating that no multi-session undo log is active for any memory location corresponding to the metadata data structure, accessing the session id value in the metadata data structure; and using the session id value in the metadata data structure as an index to a session list structure, which stores the resource counter.

[0089] In Example 4, the subject matter described in Examples 1 to 3 includes, wherein identifying the resource counter based on the multi-session bit field and the session id field of the metadata data structure corresponding to the first physical memory location includes: determining that the multi-session bit field is set to a value indicating that a multi-session undo log is active for the memory location corresponding to the metadata data structure; in response to determining that the multi-session bit field is set to a value indicating that a multi-session undo log is active for the memory location corresponding to the metadata data structure, accessing an index value in the metadata data structure; using the index value in the metadata data structure as an index to a multi-session list structure, the multi-session list structure storing a plurality of data pairs including a mask value and a session id value, each of the mask values ​​having a corresponding bit corresponding to each of the memory locations of the metadata data structure; identifying a data pair among the plurality of data pairs, wherein the mask value indicates that the first physical memory location is part of the undo log session; and utilizing the session id value from the identified data pair as an index to a session list structure, the session list structure storing the resource counter.

[0090] In Example 5, the subject matter described in Examples 1 to 4 includes: receiving a second write request for a second physical memory location of the memory device; in response to the second write request: identifying the resource counter based on a second multi-session bit field and a second session id field of a second metadata data structure corresponding to the second physical memory location; determining that the undo log session has no remaining reserved resources based on the resource counter; and in response to determining that the undo log session has no remaining resources: marking an error field in the second metadata data structure corresponding to the second physical memory location.

[0091] In Example 6, the subject matter of Examples 1-5 includes setting the resource counter of the undo log session to a specified value in a session list in response to receiving the indication of the initiation of the undo log session.

[0092] In Example 7, the subject matter of Examples 1 to 6 includes wherein the indication of the start of the undo log session includes the number of memory blocks allocated to the undo log session, and wherein the method further includes setting the resource counter of the undo log session in a session list to the number of memory blocks allocated to the undo log session included in the indication of the start of the undo log session.

[0093] Example 8 is a computing device comprising: a processor; a memory storing instructions that, when executed by the processor, cause the computing device to perform operations including: receiving an indication of the start of an undo log session from an application, the indication of the start of the undo log session identifying a set of physical memory locations of a memory device; receiving a write request for a first physical memory location of the memory device, the first physical memory location being within the set of physical memory locations of the memory device, the first physical memory location not being written to during the undo log session; in response to the write request: identifying a resource counter based on a multi-session bit field and a session id field of a metadata data structure corresponding to the first physical memory location; determining that the undo log session has remaining memory resources based on the resource counter; in response to determining that the undo log session has remaining resources: decrementing the resource counter; allocating a second physical memory location of the memory device; and updating at least one bit of the metadata data structure from indicating that the memory request is to be serviced at the first physical memory location to indicating that the memory request is to be serviced at the second physical memory location; and servicing the write request using the second physical memory location.

[0094] In Example 9, the subject matter of Example 8 includes wherein the memory device is a persistent memory device connected to a host using an interface configured for a Compute Express Link (CXL) protocol.

[0095] In Example 10, the subject matter described in Examples 8 to 9 includes, wherein the operation of identifying the resource counter based on the multi-session bit field and the session id field of the metadata data structure corresponding to the first physical memory location includes: determining that the multi-session bit field is set to a value indicating that no multi-session undo log is active for any memory location corresponding to the metadata data structure; in response to determining that the multi-session bit field is set to a value indicating that no multi-session undo log is active for any memory location corresponding to the metadata data structure, accessing the session id value in the metadata data structure; and using the session id value in the metadata data structure as an index to a session list structure, which stores the resource counter.

[0096] In Example 11, the subject matter of Examples 8 to 10 includes, wherein the operation of identifying the resource counter based on the multi-session bit field and the session id field of the metadata data structure corresponding to the first physical memory location includes: determining that the multi-session bit field is set to a value indicating that a multi-session undo log is active for the memory location corresponding to the metadata data structure; in response to determining that the multi-session bit field is set to a value indicating that a multi-session undo log is active for the memory location corresponding to the metadata data structure, accessing an index value in the metadata data structure; using the index value in the metadata data structure as an index to a multi-session list structure, the multi-session list structure storing a plurality of data pairs including a mask value and a session id value, each of the mask values ​​having a corresponding bit corresponding to each of the memory locations of the metadata data structure; identifying a data pair among the plurality of data pairs, wherein the mask value indicates that the first physical memory location is part of the undo log session; and utilizing the session id value from the identified data pair as an index to a session list structure, the session list structure storing the resource counter.

[0097] In Example 12, the subject matter according to Examples 8 to 11 includes, wherein the operation further includes: receiving a second write request for a second physical memory location of the memory device; in response to the second write request: identifying the resource counter based on a second multi-session bit field and a second session id field of a second metadata data structure corresponding to the second physical memory location; determining that the undo log session has no remaining reserved resources based on the resource counter; and in response to determining that the undo log session has no remaining resources: marking an error field in the second metadata data structure corresponding to the second physical memory location.

[0098] In Example 13, the subject matter of Examples 8-12 includes wherein the operations further comprise setting the resource counter of the undo log session to a specified value in a session list in response to receiving the indication of the initiation of the undo log session.

[0099] In Example 14, the subject matter of Examples 8 to 13 includes wherein the indication of the start of the undo log session includes the number of memory blocks allocated to the undo log session, and wherein the operation further includes setting the resource counter of the undo log session in a session list to the number of memory blocks allocated to the undo log session included in the indication of the start of the undo log session.

[0100] Example 15 is a non-transitory machine-readable medium storing instructions that, when executed by a machine, cause the machine to perform operations including: receiving an indication of the start of an undo log session from an application, the indication of the start of the undo log session identifying a set of physical memory locations of a memory device; receiving a write request for a first physical memory location of the memory device, the first physical memory location being within the set of physical memory locations of the memory device, the first physical memory location not being written to during the undo log session; in response to the write request: identifying a resource counter based on a multi-session bit field and a session id field of a metadata data structure corresponding to the first physical memory location; determining that the undo log session has remaining memory resources based on the resource counter; in response to determining that the undo log session has remaining resources: decrementing the resource counter; allocating a second physical memory location of the memory device; and updating at least one bit of the metadata data structure from indicating that the memory request is to be serviced at the first physical memory location to indicating that the memory request is to be serviced at the second physical memory location; and servicing the write request using the second physical memory location.

[0101] In Example 16, the subject matter of Example 15 includes wherein the memory device is a persistent memory device connected to a host using an interface configured for a Compute Express Link (CXL) protocol.

[0102] In Example 17, the subject matter of Examples 15 to 16 includes, wherein the operation of identifying the resource counter based on the multi-session bit field and the session id field of the metadata data structure corresponding to the first physical memory location includes: determining that the multi-session bit field is set to a value indicating that no multi-session undo log is active for any memory location corresponding to the metadata data structure; in response to determining that the multi-session bit field is set to a value indicating that no multi-session undo log is active for any memory location corresponding to the metadata data structure, accessing the session id value in the metadata data structure; and using the session id value in the metadata data structure as an index to a session list structure that stores the resource counter.

[0103] In Example 18, the subject matter of Examples 15 to 17 includes, wherein the operation of identifying the resource counter based on the multi-session bit field and the session id field of the metadata data structure corresponding to the first physical memory location includes: determining that the multi-session bit field is set to a value indicating that a multi-session undo log is active for the memory location corresponding to the metadata data structure; in response to determining that the multi-session bit field is set to a value indicating that a multi-session undo log is active for the memory location corresponding to the metadata data structure, accessing an index value in the metadata data structure; using the index value in the metadata data structure as an index to a multi-session list structure, the multi-session list structure storing a plurality of data pairs including a mask value and a session id value, each of the mask values ​​having a corresponding bit corresponding to each of the memory locations of the metadata data structure; identifying a data pair among the plurality of data pairs, wherein the mask value indicates that the first physical memory location is part of the undo log session; and utilizing the session id value from the identified data pair as an index to a session list structure, the session list structure storing the resource counter.

[0104] In Example 19, the subject matter described in Examples 15 to 18 includes, wherein the operation further includes: receiving a second write request for a second physical memory location of the memory device; in response to the second write request: identifying the resource counter based on a second multi-session bit field and a second session id field of a second metadata data structure corresponding to the second physical memory location; determining that the undo log session has no remaining reserved resources based on the resource counter; and in response to determining that the undo log session has no remaining resources: marking an error field in the second metadata data structure corresponding to the second physical memory location.

[0105] In Example 20, the subject matter of Examples 15-19 includes wherein the operations further comprise setting the resource counter of the undo log session to a specified value in a session list in response to receiving the indication of the initiation of the undo log session.

[0106] In Example 21, the subject matter of Examples 15 to 20 includes wherein the indication of the start of the undo log session includes the number of memory blocks allocated to the undo log session, and wherein the operation further includes setting the resource counter of the undo log session in a session list to the number of memory blocks allocated to the undo log session included in the indication of the start of the undo log session.

[0107] Example 22 is a device comprising: a component for receiving an indication of the start of an undo log session from an application, the indication of the start of the undo log session identifying a set of physical memory locations of a memory device; a component for receiving a write request for a first physical memory location of the memory device, the first physical memory location being within the set of physical memory locations of the memory device, the first physical memory location not being written to during the undo log session; a component for performing the following in response to the write request: identifying a resource counter based on a multi-session bit field and a session id field of a metadata data structure corresponding to the first physical memory location; determining that the undo log session has remaining memory resources based on the resource counter; in response to determining that the undo log session has remaining resources: decrementing the resource counter; allocating a second physical memory location of the memory device; and updating at least one bit of the metadata data structure from indicating that the memory request is to be serviced at the first physical memory location to indicating that the memory request is to be serviced at the second physical memory location; and a component for servicing the write request using the second physical memory location.

[0108] In Example 23, the subject matter of Example 22 includes wherein the memory device is a persistent memory device connected to a host using an interface configured for a Compute Express Link (CXL) protocol.

[0109] In Example 24, the subject matter of Examples 22 to 23 includes, wherein the means for identifying the resource counter based on the multi-session bit field and the session id field of the metadata data structure corresponding to the first physical memory location includes: means for determining that the multi-session bit field is set to a value indicating that no multi-session undo log is active for any memory location corresponding to the metadata data structure; means for accessing the session id value in the metadata data structure in response to determining that the multi-session bit field is set to a value indicating that no multi-session undo log is active for any memory location corresponding to the metadata data structure; and means for using the session id value in the metadata data structure as an index to a session list structure, the session list structure storing the resource counter.

[0110] In Example 25, the subject matter of Examples 22-24 includes, wherein the means for identifying the resource counter based on the multi-session bit field and the session id field of the metadata data structure corresponding to the first physical memory location comprises: means for determining that the multi-session bit field is set to a value indicating that a multi-session undo log is active for the memory location corresponding to the metadata data structure; means for accessing an index value in the metadata data structure in response to determining that the multi-session bit field is set to a value indicating that a multi-session undo log is active for the memory location corresponding to the metadata data structure; means for using the index value in the metadata data structure as an index to a multi-session list structure, the multi-session list structure storing a plurality of data pairs including a mask value and a session id value, each of the mask values ​​having a corresponding bit corresponding to each of the memory locations of the metadata data structure; means for identifying a data pair of the plurality of data pairs, wherein the mask value indicates that the first physical memory location is part of the undo log session; and means for utilizing the session id value from the identified data pair as an index to a session list structure, the session list structure storing the resource counter.

[0111] In Example 26, the subject matter described in Examples 22 to 25 includes a component for receiving a second write request for a second physical memory location of the memory device; a component for performing the following in response to the second write request: identifying the resource counter based on a second multi-session bit field and a second session id field of a second metadata data structure corresponding to the second physical memory location; determining that the undo log session has no remaining reserved resources based on the resource counter; and in response to determining that the undo log session has no remaining resources: marking an error field in the second metadata data structure corresponding to the second physical memory location.

[0112] In Example 27, the subject matter of Examples 22-26 includes means for setting the resource counter of the undo log session to a specified value in a session list in response to receiving the indication of the initiation of the undo log session.

[0113] In Example 28, the subject matter of Examples 22 to 27 includes wherein the indication of the start of the undo log session includes the number of memory blocks allocated to the undo log session, and wherein the device further includes a component for setting the resource counter of the undo log session in a session list to the number of memory blocks allocated to the undo log session included in the indication of the start of the undo log session.

[0114] Example 29 is at least one machine-readable medium comprising instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any of Examples 1-28.

[0115] Example 30 is an apparatus including means for implementing any one of Examples 1-28.

[0116] Example 31 is a system for implementing any one of Examples 1 to 28.

[0117] Example 32 is a method for implementing any one of Examples 1 to 28.

Claims

1. A method comprising: receiving, from an application, an indication of initiation of an undo journal session, said indication of said initiation of said undo journal session identifying a set of physical memory locations of a memory device; receiving a write request for a first physical memory location of the memory device, the first physical memory location being within the set of physical memory locations of the memory device, the first physical memory location not being written to during the undo log session; In response to the write request: identifying a resource counter based on a multi-session bit field and a session id field of a metadata data structure corresponding to the first physical memory location; determining, based on the resource counter, that the undo log session has remaining memory resources; In response to determining that the undo log session has remaining resources: decrementing the resource counter; allocating a second physical memory location of the memory device; and updating at least one bit of the metadata data structure from indicating that a memory request is to be serviced at the first physical memory location to indicating that a memory request is to be serviced at the second physical memory location; as well as The write request is serviced using the second physical memory location.

2. The method of claim 1, wherein the memory device is a persistent memory device connected to a host using an interface configured for a Compute Express Link (CXL) protocol.

3. The method of claim 1 , wherein identifying the resource counter based on the multi-session bit field and the session id field of the metadata data structure corresponding to the first physical memory location comprises: determining that the multi-session bit field is set to a value indicating that no multi-session undo log is active for any memory location corresponding to the metadata data structure; responsive to determining that the multi-session bit field is set to a value indicating that no multi-session undo log is active for any memory location corresponding to the metadata data structure, accessing a session id value in the metadata data structure; and The session id value in the metadata data structure is used as an index into a session list structure that stores the resource counter.

4. The method of claim 1 , wherein identifying the resource counter based on the multi-session bit field and the session id field of the metadata data structure corresponding to the first physical memory location comprises: determining that the multi-session bit field is set to a value indicating that a multi-session undo log is active for a memory location corresponding to the metadata data structure; responsive to determining that the multi-session bit field is set to a value indicating that a multi-session undo log is active for a memory location corresponding to the metadata data structure, accessing an index value in the metadata data structure; using the index value in the metadata data structure as an index into a multi-session list structure storing a plurality of data pairs including a mask value and a session id value, each of the mask values ​​having a corresponding bit corresponding to each of the memory locations of the metadata data structure; identifying a data pair of the plurality of data pairs in which the mask value indicates that the first physical memory location is part of the undo log session; and The session id value from the identified data pair is used as an index into a session list structure that stores the resource counter.

5. The method according to claim 1, further comprising: receiving a second write request for a second physical memory location of the memory device; In response to the second write request: identifying the resource counter based on a second multi-session bit field and a second session id field of a second metadata data structure corresponding to the second physical memory location; determining, based on the resource counter, that the undo log session has no remaining reserved resources; and In response to determining that the undo log session has no remaining resources: An error field is marked in the second metadata data structure corresponding to the second physical memory location.

6. The method of claim 1, further comprising setting the resource counter of the undo log session to a specified value in a session list in response to receiving the indication of the initiation of the undo log session.

7. A method according to claim 1, wherein the indication of the start of the undo log session includes the number of memory blocks allocated to the undo log session, and wherein the method further includes setting the resource counter of the undo log session in a session list to the number of memory blocks allocated to the undo log session included in the indication of the start of the undo log session.

8. A computing device comprising: processor; a memory storing instructions that, when executed by the processor, cause the computing device to perform operations including: receiving, from an application, an indication of initiation of an undo journal session, said indication of said initiation of said undo journal session identifying a set of physical memory locations of a memory device; receiving a write request for a first physical memory location of the memory device, the first physical memory location being within the set of physical memory locations of the memory device, the first physical memory location not being written to during the undo log session; In response to the write request: identifying a resource counter based on a multi-session bit field and a session id field of a metadata data structure corresponding to the first physical memory location; determining, based on the resource counter, that the undo log session has remaining memory resources; In response to determining that the undo log session has remaining resources: decrementing the resource counter; allocating a second physical memory location of the memory device; and updating at least one bit of the metadata data structure from indicating that a memory request is to be serviced at the first physical memory location to indicating that a memory request is to be serviced at the second physical memory location; as well as The write request is serviced using the second physical memory location.

9. The computing device of claim 8, wherein the memory device is a persistent memory device connected to a host using an interface configured for a Compute Express Link (CXL) protocol.

10. The computing device of claim 8, wherein the operation of identifying the resource counter based on the multi-session bit field and the session id field of the metadata data structure corresponding to the first physical memory location comprises: determining that the multi-session bit field is set to a value indicating that no multi-session undo log is active for any memory location corresponding to the metadata data structure; responsive to determining that the multi-session bit field is set to a value indicating that no multi-session undo log is active for any memory location corresponding to the metadata data structure, accessing a session id value in the metadata data structure; and The session id value in the metadata data structure is used as an index into a session list structure that stores the resource counter.

11. The computing device of claim 8, wherein the operation of identifying the resource counter based on the multi-session bit field and the session id field of the metadata data structure corresponding to the first physical memory location comprises: determining that the multi-session bit field is set to a value indicating that a multi-session undo log is active for a memory location corresponding to the metadata data structure; responsive to determining that the multi-session bit field is set to a value indicating that a multi-session undo log is active for a memory location corresponding to the metadata data structure, accessing an index value in the metadata data structure; using the index value in the metadata data structure as an index into a multi-session list structure storing a plurality of data pairs including a mask value and a session id value, each of the mask values ​​having a corresponding bit corresponding to each of the memory locations of the metadata data structure; identifying a data pair of the plurality of data pairs in which the mask value indicates that the first physical memory location is part of the undo log session; and The session id value from the identified data pair is used as an index into a session list structure that stores the resource counter.

12. The computing device of claim 8, wherein the operations further comprise: receiving a second write request for a second physical memory location of the memory device; In response to the second write request: identifying the resource counter based on a second multi-session bit field and a second session id field of a second metadata data structure corresponding to the second physical memory location; determining, based on the resource counter, that the undo log session has no remaining reserved resources; and In response to determining that the undo log session has no remaining resources: An error field is marked in the second metadata data structure corresponding to the second physical memory location.

13. The computing device of claim 8, wherein the operations further comprise setting the resource counter of the undo log session to a specified value in a session list in response to receiving the indication of the initiation of the undo log session.

14. A computing device according to claim 8, wherein the indication of the start of the undo log session includes the number of memory blocks allocated to the undo log session, and wherein the operation further includes setting the resource counter of the undo log session in a session list to the number of memory blocks allocated to the undo log session included in the indication of the start of the undo log session.

15. A non-transitory machine-readable medium storing instructions that, when executed by a machine, cause the machine to perform operations comprising: receiving, from an application, an indication of initiation of an undo journal session, said indication of said initiation of said undo journal session identifying a set of physical memory locations of a memory device; receiving a write request for a first physical memory location of the memory device, the first physical memory location being within the set of physical memory locations of the memory device, the first physical memory location not being written to during the undo log session; In response to the write request: identifying a resource counter based on a multi-session bit field and a session id field of a metadata data structure corresponding to the first physical memory location; determining, based on the resource counter, that the undo log session has remaining memory resources; In response to determining that the undo log session has remaining resources: decrementing the resource counter; allocating a second physical memory location of the memory device; and updating at least one bit of the metadata data structure from indicating that a memory request is to be serviced at the first physical memory location to indicating that a memory request is to be serviced at the second physical memory location; as well as The write request is serviced using the second physical memory location.

16. The non-transitory machine-readable medium of claim 15, wherein the memory device is a persistent memory device connected to a host using an interface configured for a Compute Express Link (CXL) protocol.

17. The non-transitory machine-readable medium of claim 15, wherein the operation of identifying the resource counter based on the multi-session bit field and the session id field of the metadata data structure corresponding to the first physical memory location comprises: determining that the multi-session bit field is set to a value indicating that no multi-session undo log is active for any memory location corresponding to the metadata data structure; responsive to determining that the multi-session bit field is set to a value indicating that no multi-session undo log is active for any memory location corresponding to the metadata data structure, accessing a session id value in the metadata data structure; and The session id value in the metadata data structure is used as an index into a session list structure that stores the resource counter.

18. The non-transitory machine-readable medium of claim 15, wherein the operation of identifying the resource counter based on the multi-session bit field and the session id field of the metadata data structure corresponding to the first physical memory location comprises: determining that the multi-session bit field is set to a value indicating that a multi-session undo log is active for a memory location corresponding to the metadata data structure; responsive to determining that the multi-session bit field is set to a value indicating that a multi-session undo log is active for a memory location corresponding to the metadata data structure, accessing an index value in the metadata data structure; using the index value in the metadata data structure as an index into a multi-session list structure storing a plurality of data pairs including a mask value and a session id value, each of the mask values ​​having a corresponding bit corresponding to each of the memory locations of the metadata data structure; identifying a data pair of the plurality of data pairs in which the mask value indicates that the first physical memory location is part of the undo log session; and The session id value from the identified data pair is used as an index into a session list structure that stores the resource counter.

19. The non-transitory machine-readable medium of claim 15, wherein the operations further comprise: receiving a second write request for a second physical memory location of the memory device; In response to the second write request: identifying the resource counter based on a second multi-session bit field and a second session id field of a second metadata data structure corresponding to the second physical memory location; determining, based on the resource counter, that the undo log session has no remaining reserved resources; and In response to determining that the undo log session has no remaining resources: An error field is marked in the second metadata data structure corresponding to the second physical memory location.

20. The non-transitory machine-readable medium of claim 15, wherein the operations further comprise setting the resource counter of the undo log session to a specified value in a session list in response to receiving the indication of the initiation of the undo log session.

Images