Kernel memory monitoring for user space mapping change notification

Abstract

The invention relates to kernel memory monitoring for user space mapping change notification. A system performs a registration procedure for monitoring respective address ranges by: receiving a first command from an application to monitor a first address range in a kernel; registering a first address range in the kernel; creating a monitoring state window in the kernel, wherein the monitoring state window indicates that the first address range is valid; and providing read-only access to the monitoring state window to the application. The system detects, in the kernel, a change associated with a memory mapping of the second address range based on a previous state of the mapping of virtual addresses to physical addresses. The system updates the monitoring state window by invalidating an address range that overlaps the second address range. In response to the first address range being valid, the system bypasses the registration procedure for the first address range.

Description

[0001] Related Applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 541,633 (Attorney Docket No. P172103USPRV), filed on September 29, 2023 by inventor Michael J. Uttormark, entitled “KERNEL MEMORY MONITOR FOR USER-SPACE MAPPING CHANGE NOTIFICATIONS.” Background Art

[0003] field

[0004] Remote Direct Memory Access (RDMA) operations can be used to bypass normal memory protection to improve application performance, but RDMA operations require memory registration, which incurs computational overhead. Current RDMA technology allows operations on physical addresses mapped to virtual addresses used by applications, but changes in the underlying memory mapping may cause failures or data corruption. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 An environment for facilitating kernel memory monitoring to provide mapping change notifications to user space in accordance with aspects of the present application is illustrated.

[0006] Figure 2 An environment for facilitating kernel memory monitoring to provide mapping change notifications to user space according to aspects of the present application is illustrated, including data structures that are updated based on registration and mapping change notifications.

[0007] Figure 3 A flow chart is presented illustrating a method for facilitating kernel memory monitoring that provides mapping change notifications to user space in accordance with aspects of the present application.

[0008] Figure 4A A flow chart is presented illustrating a method for facilitating kernel memory monitoring to provide mapping change notifications to user space according to aspects of the present application, including performing a registration process.

[0009] Figure 4B A flow chart is presented illustrating a method for facilitating kernel memory monitoring to provide mapping change notifications to user space according to aspects of the present application, including actions performed in response to detecting a mapping change.

[0010] Figure 4CA flow chart is presented illustrating a method for facilitating kernel memory monitoring to provide mapping change notifications to user space, including conditions for bypassing a registration process, according to aspects of the present application.

[0011] Figure 5 A flow chart is presented illustrating a method for facilitating kernel memory monitoring to provide mapping change notifications to user space according to aspects of the present application, including performing an unregistration process.

[0012] Figure 6 A computer system for facilitating kernel memory monitoring to provide mapping change notifications to user space in accordance with aspects of the present application is illustrated.

[0013] Figure 7 A non-transitory computer-readable medium for facilitating kernel memory monitoring to provide mapping change notifications to user space in accordance with aspects of the present application is illustrated.

[0014] In the drawings, like reference numerals refer to the same drawing elements. DETAILED DESCRIPTION

[0015] Aspects of the present application provide a system and method that facilitates kernel memory monitoring by placing a user space cache between an application in user space and a memory registration in the kernel. The kernel can create a monitoring status window that is updated based on changes in the memory mapping and is accessible to the user space as a read-only data structure. By using certain key identification information (e.g., cookies and unique generation numbers) to track memory registrations, an application can check the status of a previously registered address range in the monitoring status window and bypass subsequent memory registrations based on the status when reusing a previously registered address range. Bypassing the registration process can allow the same memory location to be reused, thereby eliminating expensive registration and deregistration processes and resulting in improved execution efficiency of RDMA operations.

[0016] As described above, using RDMA operations to directly transfer data can result in improved performance for user applications. In order for an application to use RDMA operations for direct data transfer, the application must "register" memory locations for the source and destination of the RDMA operation. This registration process may be referred to as "memory registration." Applications may operate on virtual addresses that are mapped to physical addresses. The network adapter may work inside an operating system (OS) and operate on physical addresses. After the memory registration process, the network adapter may directly transfer data in and out of these locations without using any intermediate buffers, i.e., by determining the corresponding physical addresses to be used for direct data transfer.

[0017] However, an application or the OS may perform actions that cause a change in the mapping of virtual addresses to physical addresses (i.e., a change in the "memory mapping"). For example, an application may cause memory to become freed, or the OS may rearrange memory operations as part of performing a swap operation. These actions may not be visible to the application and may be initiated by an intermediate library or subsystem. Regardless of the reason for initiating the entity or memory mapping change, these actions may cause inaccurate memory registrations, which in turn may cause future data transfer failures, data corruption, or other errors. For example, if the memory location being read has changed, incorrect data may be returned, which may cause problems for the requesting application. Similarly, if the memory location being written has changed, inaccurate or incorrect data may be written to the wrong location, which may cause problems for other applications that rely on the data stored in that memory location.

[0018] One technique to address these challenges is to implement memory monitoring. Memory monitoring can detect memory map changes and unregister the appropriate memory ranges from the system's memory registration component. In one technique, a userspace solution allows applications to access memory allocation and deallocation functions, including memory release functions. This userspace solution can track whether an application is using a certain address and whether the application has released the address. However, this userspace solution cannot access all functions that can change the underlying memory map. As a result, this userspace solution may miss certain triggering events, such as stack allocations that are controlled by the operating system and may not be overwritten by the application.

[0019] Another technique provides a facility in the Linux kernel that can help a virtual machine migrate from a first host to a second host. During the background copy of data from the first host to the second host, if a failure occurs, the kernel can notify the memory cache of the failure so that the memory cache can be cleared. However, the monitoring thread of the memory cache resides in user space and may be scheduled like other threads. As a result, such notifications cannot be executed in real time (i.e., not synchronously with the underlying mapping changes). These asynchronous notifications can also cause inaccurate memory registrations.

[0020] In another technique, memory monitoring can mark a global flag to indicate that the memory mapping of any monitored address or address range has changed. In order to determine whether a specific memory mapping has changed, the memory registration cache can check the global flag. If the global flag is set, the application can stop all pending actions or threads, read from the file descriptor to obtain the changed events (i.e., all changed memory mappings), modify the memory registration cache based on the information read from the file descriptor, and resume the suspended actions or threads. However, in this technique, the application must perform several steps (including locking all active threads) in order to obtain memory changes and update the cache. Especially in a multi-threaded environment, these steps will degrade the performance of memory monitoring and therefore degrade the performance of the entire system.

[0021] The described aspects of the present application address these limitations by providing a system that: monitors all memory mapping address changes in the kernel (rather than just in user space); provides synchronous notification of memory mapping changes to applications (rather than asynchronous notification); and implements cached per-registration notifications to determine specific memory mapping changes (rather than a global flag that requires reading all memory mapping changes from a file descriptor to determine a specific memory mapping change).

[0022] The described aspects of the system can perform a registration process that updates a registration database and a monitoring status window in the kernel and can further return certain identification information to the cache. The system can utilize mapping change notifications from the kernel to update both the registration database and the monitoring status window. An application can access the monitoring status window as a read-only data structure and determine based on the cache whether the registration process can be bypassed when using a certain address range.

[0023] An environment for facilitating kernel memory monitoring that provides mapping change notifications to userspace

[0024] Figure 1An environment 100 for facilitating kernel memory monitoring for providing mapping change notifications to user space according to aspects of the present application is illustrated. The environment 100 may include a user space 102 and a kernel space 104. The kernel space 104 may include memory areas for running an operating system kernel, kernel extensions, and some device drivers, while the user space 102 may include memory areas for running applications or other code outside the kernel of the operating system. The environment 100 may represent a computing node or entity, such as a server, a computer system, or other computing device including a user space and a kernel space. The environment 100 may include an application 110 with a cache 112 in the user space 102. The cache 112 may be a memory registration cache implemented by a transport library (e.g., Libfabric, Open Fabric Interface (OFI) or any other transport library). Environment 100 may also include in kernel space 104: file descriptors 120, which may be process unique identifiers for files or other input / output (I / O) resources; status windows 122; monitoring status windows 130; command application programming interfaces (APIs) 124; event queues 126 to which events may be posted when an address is invalid in the monitoring status window; a registration database 140; and an operating system (OS) memory management system 150. Applications 110 may have read and write access to file descriptors 120 and status windows 122. Applications 110 may have read-only access to monitoring status windows 130. Figure 2 The application 110 , the cache 112 , the monitoring status window 130 , the registration database 140 , and the OS memory management system 150 are described in detail with reference to the application 210 , the cache 212 , the monitoring status window 260 , the registration database 240 , and the OS memory management system 280 .

[0025] --Initialize kernel memory monitoring

[0026] During setup or initialization of kernel memory monitoring, application 110 may issue a command to initialize the memory registration process, such as by using a library and making an input / output control (ioctl()) system call (via 160) to file descriptor 120. The command may indicate a maximum size for registration database 140. The command results in setting up status window 122 and registration database 140 (based on the indicated sizes) and creating a new instance of monitoring status window 130. Additionally, the system may initialize memory allocation routines of the kernel's OS memory management system (or subsystem).

[0027] --Execute the registration process

[0028] After initializing kernel memory monitoring, application 110 may determine to use an address range for, for example, an input / output (I / O) command. Application 110 may register an address range by issuing a command to register the address range for monitoring (via 160). File descriptor 120 may send the command to command API 124 (via 166). Command API 124 may send relevant information (such as the memory range to be monitored) to registration database 140 (via 170). Upon receiving the information, registration database 140 may create an entry with identifying information, as described below with respect to Figure 2 The registration database 140 may also send (via 174) statistical information to the status window 122, the statistical information relating to, for example, the number of active registrations, the number of invalidations processed, and information relating to the occupancy of the event queue 126. The application 110 may view the statistical information, which is provided to the status window 122 (via 162), such as on a display screen (not shown) of a device associated with the application 110. In addition, the registration database 140 may allocate an element in the monitoring status window 130 and set it as valid (via 176) by sending information relating to an address range registered for monitoring, as described below with respect to Figure 2 The application 110 may use the information in the monitoring status window 130 (via 164) to determine whether a particular address range is valid. Upon determining that the particular address range is valid, the application 110 may bypass the memory registration process for subsequent I / O commands involving the particular address range.

[0029] --Handle memory map change notification

[0030] The memory management system 150 can manage and detect memory mapping changes, and can be based on, for example, the Linux kernel. When a memory mapping change is detected, the memory management system 150 can send a notification message (e.g., a Linux memory management unit (mmu) call or an "mmu_notifier" message) to the registration database 140 (via 180). The notification message can indicate that the underlying memory mapping has changed, that is, for a specific address range, the mapping of virtual addresses to physical addresses has changed. The mmu_notifier call is used in the present disclosure as a non-limiting example of a Linux-specific kernel mechanism that provides information about memory mapping changes. Other mechanisms (including other entities or components) can be used to provide information about memory mapping changes while prohibiting user space from changing memory mappings. The system can identify entries in the registration database 140 that have an address range that overlaps with a specific changed address range. The system can identify the corresponding element in the monitoring status window 130 and set it to invalid, and can further remove the entry from the registration database 140. The system may also send invalid indication(s) to the event queue 126 (via 172), which may be sent back to the file descriptor 120 (via 168) and ultimately displayed as statistics in the status window 122 (via 174).

[0031] In addition to processing memory map change notifications, aspects of the described system can also bypass registration for valid address ranges and unregister previously registered address ranges, as described below with respect to Figure 2 as described.

[0032] Update data structures based on memory registration and memory map change notification; bypass registration; cancel registration

[0033] Figure 2 An environment 200 for facilitating kernel memory monitoring for providing mapping change notifications to user space according to aspects of the present application is illustrated, including data structures that are updated based on registration and mapping change notifications. Environment 200 may include: application 210 (in user space) with cache 212; monitoring status window 260 (in kernel space and accessible to application 210 as a read-only data structure); registration database 240 (in kernel space); and operating system (OS) memory management system 280. The entities depicted in environment 200 may be similar to those depicted in environment 100. For illustration purposes, only certain entities from environment 100 are included in environment 200, for example: application 210 may correspond to application 110; registration database 240 may correspond to registration database 140; monitoring status window 260 may correspond to monitoring status window 130; and OS memory management system 280 may correspond to OS memory management system 150.

[0034] --Execute the registration process

[0035] Assuming that kernel memory monitoring has been initialized in environment 200, application 210 may determine to use a first address range for I / O operations. Application 210 may perform a registration process for the first address range by issuing command 202 to registration database 240. Command 202 may include the first address range and a cookie generated by application 210 as an identifier of command 202. A transport library implementing cache 212 may use, for example, a 64-bit atomic counter to generate a unique cookie across all threads in application 210 or any other means of generating a unique identifier across all threads in application 210. The cookie (or other unique identifier) ​​may be a small data block or a small file that may include a string (e.g., a 64-bit value or other uniquely generated identifier). Application 210 may use the cookie (or other unique identifier) ​​when subsequently searching registration database 240 to determine whether an entry for a particular memory range still exists.

[0036] The application 210 may track the memory registration requested in the command 202 by storing information in a cache 212. The cache 212 may include entries with various information, as indicated by a row 220 consisting of multiple columns, the row including: an address range 222, an index 224 of a corresponding monitor status window (MSW) element, a cookie 226; and a generation number 228. Prior to completing the registration process, only the address range (222) and cookie (226) fields may be known. After completing the registration process, the index (224) and generation number (228) fields may be updated as described below. For example, prior to completing the registration process, a cache entry 230 corresponding to the command 202 may include: an address range having a value of "AR_1" (such as, 0-99); and a cookie having a value of "cookie_value" (e.g., a 64-bit value or any other unique generation identifier).

[0037] Upon receiving command 202, registration database 240 may create an entry that stores a first address range, a cookie, and an index of a slot or element to be allocated in monitoring state window 260. In registration database 240, row 250 may indicate columns or information of an entry in registration database 240, the row including: address range 252; index 254 of a corresponding monitoring state window (MSW) element; and cookie 256. For example, entry 258 corresponding to command 202 may include: address range having a value of "AR_1" (such as 0-99); index of a MSW element having a value of "12"; and cookie having a value of "cookie_value" (e.g., a 64-bit value or any other uniquely generated identifier).

[0038] The system may allocate and set the element as valid in monitoring status window 260 based on the index of the monitoring status window element (via 204). In monitoring status window 260, row 270 may indicate fields of the element in monitoring status window 260, including: an index 272 of the MSW element; a unique generation number 274; and a status 276. For example, element 278 may include: an index of the MSW element having a value of "12"; a generation number having a value of "2468"; and a status set to "valid".

[0039] The generation number 274 may be a unique number generated for a particular element, such as a fixed-size number that is incremented by 1 for each subsequent generation. The generation number 274 may be used to indicate to the application 210 whether an entry with an address range and the same generation number is still valid, thereby allowing the application 210 to bypass the memory registration process for the address range.

[0040] The system may return registration information 206 (including the MSW index and generation number for the corresponding address range of command 202) to application 210. Application 210 may update cache entry 230 to include: the index of the MSW element, which has a value of "12"; and the generation number, which has a value of "2468".

[0041] --Handle memory map change notification

[0042] During operation, OS memory management system 280 may detect or determine that the underlying memory mapping of a particular address range has changed. MMS 280 may send a notification (eg, in the form of a Linux mmu_notifier call) to registration database 240 (via 208) indicating the particular changed address range.

[0043] The system can search and identify all entries in the registration database 240 for the address range that overlaps with the address range of the specific change. The system can update the monitoring status window 260 by changing the element corresponding to the identified entry in the monitoring status window 260 (based on the index number). Specifically, for the corresponding element in the monitoring status window 260, the system can change or set the corresponding state to invalid. During this time, the kernel memory monitoring can hold a lock to prevent any thread in the application 210 from modifying the memory when the state of the element in the monitoring status window 260 is changed. As a result, the monitoring status window 260 can be used as a synchronization interface for memory mapping changes. The system can remove the identified entry from the registration database 240. The system can also send a message to an event queue (e.g., Figure 1 126, via 172) publishes an event (or (multiple) invalid indications), which may eventually be displayed in a status window (e.g., Figure 1 122 in, via 174) is displayed as statistical information. The system can release the identified elements in the monitoring status window 260 and provide updated statistical data in the status window.

[0044] --Bypass registration for valid address ranges

[0045] After registering the first address range, the application 210 may determine to use the same address range at a subsequent time (e.g., for another I / O command). If an inspection of the elements in the monitoring status window 260 indicates that the first address range is still valid, the application 210 may bypass the registration process for the first address range. Specifically, the application 210 may use the index and generation number in the cache entry 230 to obtain the element 278 corresponding to the index. If a comparison between the generation number in the cache entry 230 and the generation number in the obtained element 278 results in a match, this indicates that the element is still allocated to the first address range and has not been reallocated to a different address range. In addition, if the state of the obtained element is set to a valid state, the application 210 may bypass the registration process for the first address range. Bypassing the registration process may allow the same memory location to be reused, thereby eliminating expensive registration and deregistration processes and improving the performance of RDMA operations.

[0046] However, if the generation number does not match or the state of the acquired element is set to an invalid state, this indicates that the slot has been reallocated or invalidated. In either case, the application 210 cannot bypass the registration process for the first address range, but instead must perform the registration process for the first address range.

[0047] --Unregister a previously registered address range

[0048] The application 210 may determine to deregister a previously registered address range. The cache 212 may store entries for previously registered address ranges, and the cache entries may include a cookie ("cache entry cookie"). The application 210 may send a command 202 indicating the address range and the cache entry cookie. If the cache entry cookie is the same as the cookie in the entry for the indicated address range in the registration database 240 ("registration database cookie"), this indicates that the registration database entry corresponds to the correct previously registered address range, and the system may remove the entry from the registration database 240. However, if the cache entry cookie does not match the registration database cookie, this indicates that the registration database entry for the indicated address range corresponds to a different memory registration and therefore will not be removed from the registration database 240.

[0049] Method for facilitating kernel memory monitoring to provide mapping change notifications to user space

[0050] Figure 3 A flow chart 300 is presented, which illustrates a method for facilitating kernel memory monitoring for providing mapping change notifications to user space according to aspects of the present application. During operation, the system performs a registration process (operation 302) for monitoring a corresponding address range. Executing the registration process (302) includes the following operations 304-310. The system receives a first command (operation 304) from an application to monitor a first address range in the kernel. The command (160 or 202) may originate from an application (110 or 210) in user space and be sent to a file descriptor in kernel space based on a transport library call. The transport library may implement a memory registration cache (112 and 212) of the application. The command may include a first address range and a cookie generated by the application. The system registers the first address range in the kernel (operation 306). Registration may include creating an entry in a registration database (140 or 240), and the entry may include an address range, an index of an element to be allocated in a monitoring status window, and a cookie.

[0051] The system creates a monitoring status window (130 or 260) in the kernel, which indicates that the first address range is valid (operation 308). The monitoring status window can be an array or other data structure that is accessible to user space applications and caches as read-only data. The elements in the monitoring status window can indicate the index of the corresponding element, the generation number unique to the corresponding element, and the status (status or state) of the address range represented by the corresponding element (e.g., valid or invalid). The system provides read-only access to the monitoring status window to the application (operation 310).

[0052] The system detects a change associated with a memory mapping of the second address range based on a previous state of a mapping of virtual addresses to physical addresses in the kernel (operation 312). A memory management system or subsystem (150 or 280) of the kernel can detect the change and provide a notification (180 or 208) of the memory mapping change, such as via a Linux mmu_notifier call. The system updates the monitoring status window (130 or 260) by invalidating an address range that overlaps with the second address range (operation 314). The system can search the registration database 240 for an entry indicating an address range that overlaps with the second address range. The search can be based on an optimized or tree-based search algorithm (e.g., a red-black tree based on a self-balancing binary search tree).

[0053] In response to the first address range being valid, the system bypasses the registration process for the first address range (operation 316). Figure 2 As described, if the inspection of the elements in the monitoring status window indicates that the given address range is still valid, the system (or application) can bypass the registration process for the given address range. The operation returns.

[0054] Figure 4A A flowchart 400 is presented that illustrates a method for facilitating kernel memory monitoring for providing mapping change notifications to user space according to aspects of the present application, including performing a registration process. During operation, the system performs a registration process for monitoring a corresponding address range in the kernel (operation 402). Executing the registration process (402) includes the following operations 404-412. The system receives a first command from an application in user space to monitor a first address range in the kernel, the first command including a cookie generated by the application as an identifier of the command (operation 404, similar to operation 304). The command may originate from a user space application, and the application may maintain a memory registration cache implemented by a transport library. The command may include a first address range and a cookie generated by the application. The application may subsequently use the cookie when unregistering a previously registered memory range, for example by sending a command with a cookie associated with the previously registered memory range and unregistering the memory range based on a cookie match. A matching cookie may indicate a confirmation that an entry for the previously registered memory range exists and can therefore be removed, as described below with respect to Figure 5 as described.

[0055] The system registers the first address range in the kernel by storing the first address range, the index of the element in the second data structure, and the cookie in an entry in the first data structure (operation 406, similar to operation 306). The first data structure may be a registration database (140 or 240), and the entry may correspond to, for example Figure 2 Entry 258. The index of the element may be the index of the slot to be allocated in the monitoring status window array.

[0056] The system allocates an element in a second data structure based on an index stored in a corresponding registration database entry, the element including a unique number generated for the element and a state set to a valid state (operation 408). The second data structure can be a monitoring status window (130 or 260) or an array accessible by the application as a read-only data structure. The generation number can be a number generated by the monitoring status window, such as a fixed-size number that is incremented by 1 each time a new generation number is generated. The elements in the monitoring status window (e.g., Figure 2 Element 278 of may indicate an index, a generation number, and a state (e.g., valid or invalid). The application may use the generation number in subsequent attempts to reuse the memory location, e.g., to determine whether the application may bypass the registration process.

[0057] The system provides read-only access to the monitoring status window to the application by returning the index and unique number to the cache (112 or 212) in the user space (operation 410). The system stores the index and unique number in the cache entry for the first address range (operation 412), thereby generating a cache entry (e.g., entry 238) that includes the first address range, the corresponding index in the monitoring status window, the cookie, and the generation number. The application can then use the generation number when determining whether to bypass the registration process for a particular address range, and the application can then use the cookie to determine whether an entry for the corresponding memory range still exists in the registration database.

[0058] If the system detects a mapping change associated with the second address range (decision 414), then operation is performed at Figure 4B The change may be based on a change associated with a mapping of virtual addresses to physical addresses monitored by the kernel. The change may be detected based on a notification sent by the kernel's OS memory management subsystem (e.g., the Linux kernel OS MMS sends a notification such as an mmu_notifier call). If the system does not detect a mapping change associated with the second address range (decision 414), then operation proceeds to step 415. Figure 5 Continue or return at label C.

[0059] Figure 4BA flowchart 420 is presented, which illustrates a method for facilitating kernel memory monitoring for providing mapping change notifications to user space according to aspects of the present application, including actions performed in response to detecting a mapping change. The system identifies an address range in the first data structure that overlaps with a second address range by searching the first data structure (operation 422). The system can identify the overlapping address range based on an optimized search of a registration database (140 or 240). The system sets a corresponding state to an invalid state in an element in the second data structure corresponding to the identified address range (operation 424). Similar to operation 314, the system can update the monitoring status window (130 or 260) by invalidating the identified overlapping address range. The system publishes a record of invalidating the address range overlapping with the second address range to the event queue (126) in some aspects. The system publishes to the event queue only when an address is invalidated in the monitoring status window, for example, based on detecting a memory mapping change and receiving an mmu_notifier notification message from the kernel memory management system (150 or 280). The system removes the entry corresponding to the identified address range from the first data structure (operation 428). The system can delete the corresponding entry or insert a null value or other predetermined default value for the cookie. The null value or default value can indicate to the application that the entry for the address range no longer exists.

[0060] The application can determine whether it can reuse a previously registered address range, for example, whether it can reuse the memory location specified by the first address range for a subsequent I / O command. The system determines whether to bypass or perform the registration process for the first address range based on the index and unique number in the cache entry (operation 430). As described above with respect to Figure 2 As described, an application may bypass the registration process for a given address range if an inspection of elements in the monitoring status window indicates that the given address range is still valid.

[0061] The system retrieves an element corresponding to the index by searching the second data structure based on the index and the unique number in the cache entry of the first address range (operation 432). As in the cache entry of the first address range (230), the system can search the monitoring state window for an element with the corresponding index (278). The system performs a comparison between the unique number in the cache entry and the unique number in the retrieved element (operation 434). The system can use the generated number to decide whether to bypass or perform the registration process. Operation 434 Figure 4C Continue at label B of .

[0062] Figure 4CA flowchart 440 is presented illustrating a method for facilitating kernel memory monitoring for providing mapping change notifications to user space according to aspects of the present application, including a condition for bypassing the registration process. If the system determines based on the comparison that the unique number in the cache entry does not match the unique number in the retrieved element (decision 442), then the operation is performed at Figure 4A The system continues at operation 402, i.e., the system must perform the memory registration process again for the first address range. The system cannot bypass the memory registration process because the mismatched generation numbers (e.g., in cache entry 230 and element 278) indicate that the element has been reallocated to a different address range and is no longer allocated to the previously registered address range corresponding to the unique number in the cache entry.

[0063] If the system determines, based on the comparison, that the unique number in the cache entry does match the unique number in the retrieved element (decision 442) (e.g., the matching generation numbers in cache entry 230 and element 278), then the system determines whether the state of the retrieved element is set to a valid state (operation 444). If the state of the retrieved element is not set to a valid state (decision 446), then operation 447 is performed. Figure 4A The system continues at operation 402, i.e., the system determines that the first address range indicated in the cache entry 230 is invalid based on the state of the corresponding element 278, and therefore the memory registration process must be performed again for the first address range. The system cannot bypass the memory registration process because the first address range is no longer valid, for example, it may have been set to an invalid state due to an underlying mapping change associated with the first address range or a deregistration process for the first address range.

[0064] If the state of the retrieved element is set to a valid state (decision 446), the system determines that the first address range is valid and bypasses the registration process for the first address range (operation 448, similar to operation 316). Figure 5 440 continues at label C in . Therefore, both conditions represented by decisions 442 (matching build numbers) and 446 (address range indicates valid state) must be true in order for the application to bypass the memory registration process.

[0065] Figure 5A flow chart 500 is presented, which illustrates a method for facilitating kernel memory monitoring for providing mapping change notifications to user space according to aspects of the present application, including performing an unregistration process. The system receives a second command from an application to perform an unregistration process, the second command including a first address range and a second cookie generated by the application as an identifier of the second command (operation 502). The application can use the second cookie to determine whether the entry for the first address still exists when searching the registration database (140 or 240), i.e., in order to have the kernel remove the entry from the registration database. If the second cookie does not match the cookie in the registration database entry associated with the first address range (decision 504), the operation returns. In some aspects, the operation can return an error message for display on a status window for the user, such as as part of displayed statistics or as a separate error message.

[0066] If the second cookie does match a cookie in a registration database entry associated with the first address range (decision 504), the system removes the entry associated with the first address range from the first data structure (operation 506). The system can delete the entry with the first address range or insert a null value or other predetermined default value for the cookie. The null value or default value can indicate to the application that the entry for the first address range no longer exists. The system provides the application with read-only access to a status window of the kernel, which includes statistical information (operation 508). The statistical information can relate to at least one of: the number of active registrations; the number of invalidations processed; or information related to the occupancy of the event queue. The operation returns.

[0067] Computer system for facilitating kernel memory monitoring to provide mapping change notifications to user space

[0068] Figure 6 A computer system 600 is illustrated for facilitating kernel memory monitoring for providing mapping change notifications to user space in accordance with aspects of the present application. The computer system 600 includes a processor 602, a memory 604, and a storage device 606. The memory 604 may include a volatile memory (e.g., a random access memory (RAM)) that is used as a managed memory and may be used to store one or more memory pools. In addition, the computer system 600 may be connected to a peripheral I / O user device 610 (e.g., a display device 611, a keyboard 612, and a pointing device 613). The storage device 606 includes a non-transitory computer-readable storage medium and stores an operating system 616, a content processing system 618, and data 632. The computer system 600 may include, for example, a processor 602, a memory 604, and a storage device 606. Figure 6 Fewer or more entities or instructions than those shown.

[0069] The content processing system 618 may include instructions that, when executed by the computer system 600, cause the computer system 600 to perform the methods and / or processes described in the present disclosure. Specifically, the content processing system 618 may include instructions 620 for performing a registration process for a corresponding address range, such as: registering a first address range in a registration database of the kernel in response to a request from an application; and indicating that the first address range is valid in a monitoring status window, which is a read-only data structure for the application. The instructions 620 may also include operations associated with performing a registration process, such as those described above with respect to Figure 3 and Figure 4A Described, for example, operations 302-310 and 402-412.

[0070] The content processing system 618 may include instructions 622 to determine whether to bypass or perform the registration process, for example: determining whether to bypass the registration process for the first address range based on a command to reuse the first address range; and bypassing the registration process for the first address range in response to the first address range being valid in the monitoring status window. The instructions 622 may also include instructions as described above with respect to Figure 4B and Figure 4C Operations described, such as operations 430 , 432 , 434 , 442 , 444 , 446 , and 448 .

[0071] The content processing system 618 may include instructions 624 to process a change in the memory mapping of the second address range, such as: receiving notification of a change in the virtual-to-physical memory mapping associated with the second address range; and invalidating an address range that overlaps with the second address range in the monitoring status window. The instructions 624 may also include instructions such as regarding Figure 4A and Figure 4B Described operations, such as operations 414 and 422-428.

[0072] The content processing system 618 may include instructions 626 for managing a monitoring status window in the kernel, such as updating the monitoring status window by setting the status in the identified element to an invalid state. The instructions 626 may also include instructions for respectively Figure 1 The monitoring status window 130 and Figure 2 The operation described by the monitoring status window 260.

[0073] The content processing system 618 may include instructions 628 for performing a deregistration process, including the instructions described above with respect to Figure 5 The content processing system 618 may further include instructions 630 for displaying statistical information in the status window, including the above-mentioned instructions for displaying statistical information in the status window. Figure 5 Described operations, such as operation 508.

[0074] Data 632 may include any data required as input by the methods, operations, communications and / or processes described in the present disclosure, or any data generated as output by the methods, operations, communications and / or processes described in the present disclosure. Specifically, data 632 may store at least: commands; physical addresses; virtual addresses; address ranges; mappings of virtual addresses or address ranges to physical addresses or address ranges; cookies; a first data structure; a registration database; a second data structure; a monitoring status window; an index to the monitoring status window; entries indicating address ranges, cookies, and indexes to the monitoring status window; elements; arrays; elements indicating indexes, unique generation numbers, and states; notifications of memory map changes; records of invalid address ranges; results of comparisons between two cookies or two generation numbers; statistics; a status window; the number of active registrations; the number of invalidations processed; and information related to the occupancy of the event queue.

[0075] Non-transitory computer program product for facilitating kernel memory monitoring to provide mapping change notifications to user space Reading device

[0076] Figure 7 A non-transitory computer-readable device 700 for facilitating kernel memory monitoring for providing mapping change notifications to user space according to aspects of the present application is illustrated. The device 700 may be a non-transitory computer-readable storage medium storing instructions that, when executed by a computer, cause the computer to perform a method. The device 700 may store instructions 710 for performing (or for performing) a registration process for monitoring corresponding address ranges. The instructions 710 may include: instructions 712 for receiving a first command from an application to register a first address range in the kernel, the first command including a cookie generated by the application to identify the command; instructions 714 for registering the first address range in the kernel in response to the first command; instructions 716 for setting the first address range to a valid state in a monitoring status window in the kernel; and instructions 718 for providing read-only access to the monitoring status window to the application.

[0077] The apparatus 700 may further store instructions 720 for determining whether to bypass the registration process for the first address range based on the command to reuse the first address range. The apparatus 700 may also store instructions 722 for bypassing the registration process for the first address range in response to the first address range being valid in the monitoring status window.

[0078] The apparatus 700 may include Figure 7 For example, the device 700 may also store instructions for performing the operations described above with respect to the following: Figure 1 communication in; Figure 3 , Figure 4A , Figure 4B , Figure 4C and Figure 5 The operations depicted in the flowchart of ; and Figure 6 Instructions of the content processing system 618 in.

[0079] Various aspects and variations of the present application

[0080] In general, the disclosed aspects provide a method, computer system, and non-transitory computer-readable storage medium for facilitating kernel memory monitoring that provides mapping change notifications to user space. In one aspect, a system performs a registration process for monitoring a corresponding address range. Executing the registration process includes: receiving a first command from an application to monitor a first address range in a kernel; registering the first address range in the kernel; creating a monitoring status window in the kernel, the monitoring status window indicating that the first address range is valid; and providing read-only access to the monitoring status window to the application. The system detects a change associated with a memory mapping of a second address range based on a previous state of a mapping of a virtual address to a physical address in the kernel. The system updates the monitoring status window by invalidating an address range that overlaps with the second address range. In response to the first address range being valid, the system bypasses the registration process for the first address range.

[0081] In a variation of this aspect, the first command includes a cookie generated by the application as an identifier of the command. The registration process further includes: storing the first address range, an index of an element in a second data structure of the kernel, and the cookie in an entry in a first data structure of the kernel; allocating the element in the second data structure, the element including a unique number generated for the element and a state set to a valid state; returning the index and the unique number to a cache in user space; and storing the index and the unique number in the cache entry for the first address range.

[0082] In a further variation of this aspect, the system updates the monitoring status window by searching the first data structure to determine an address range that overlaps with the second address range.

[0083] In a further variation, the system determines whether to bypass or perform a registration process for a first address range based on an index and a unique number in a cache entry. The system retrieves an element corresponding to the index by searching a second data structure based on the index and the unique number in a cache entry for the first address range. The system performs a comparison between the unique number in the cache entry and the unique number in the retrieved element. The system determines based on the comparison that the unique number in the cache entry matches the unique number in the retrieved element. In response to the state of the retrieved element being set to a valid state, the system determines that the first address range is valid and bypasses the registration process for the first address range. In response to the state of the retrieved element being set to an invalid state, the system determines that the first address range is invalid and performs a registration process for the first address range.

[0084] In a further variation, the system receives a second command to perform a deregistration process, the second command including the first address range and a second cookie generated by the application as an identifier for the second command. In response to the second cookie matching a cookie in an entry associated with the first address range, the system removes the entry from the first data structure.

[0085] In a further variation, in response to detecting a change: the system identifies an address range in the first data structure that overlaps with the second address range; the system sets a corresponding state to an invalid state in an element in the second data structure corresponding to the identified address range; and the system removes entries corresponding to the identified address range from the first data structure.

[0086] In a further variation, the system detects the change by receiving notification of a change associated with the memory mapping of the second address range from a memory management system of the kernel.

[0087] In a further variation, upon detecting the change, the system posts a record to the event queue invalidating the address range that overlaps with the second address range.

[0088] In a further variation, the system provides the application with read-only access to a status window of the kernel, the status window including statistical information related to at least one of: the number of active registrations; the number of invalidations processed; or information related to occupancy of the event queue.

[0089] In another aspect, a computer system includes a processor and a storage device storing instructions that, when executed by the processor, cause the processor to perform a method. The method may include executing a registration process for monitoring a corresponding address range by the following steps: registering a first address range in a registration database of a kernel in response to a request from an application; and indicating that the first address range is valid in a monitoring status window, which is a read-only data structure for the application. The method may also include: determining whether to bypass the registration process for the first address range based on a command to reuse the first address range; and bypassing the registration process for the first address range in response to the first address range being valid in the monitoring status window. The method may further include: receiving a notification of a change in a virtual-to-physical memory mapping associated with a second address range; and invalidating an address range that overlaps with the second address range in the monitoring status window. The method may also include the operations described herein, including operations related to: Figure 1 communication in; Figure 3 , Figure 4A , Figure 4B , Figure 4C and Figure 5 The operations depicted in the flowchart of ; and Figure 6 Instructions of the content processing system 618 in.

[0090] In yet another aspect, a non-transitory computer-readable storage medium stores instructions that, when executed by a computer, cause the computer to perform a method. The method may include performing a registration process for monitoring a corresponding address range, the registration process comprising: receiving a first command from an application to register a first address range in a kernel, the first command comprising a cookie generated by the application to identify the command; registering the first address range in the kernel in response to the first command; setting the first address range to a valid state in a monitoring status window in the kernel; and providing read-only access to the monitoring status window to the application. The method may also include: determining whether to bypass the registration process for the first address range based on a command to reuse the first address range; and bypassing the registration process for the first address range in response to the first address range being valid in the monitoring status window. The method performed by a computer based on instructions stored in a computer-readable storage medium may also include the operations described herein, including operations related to: Figure 1 communication in; Figure 3 , Figure 4A , Figure 4B , Figure 4C and Figure 5 The operations depicted in the flowchart; Figure 7 Instructions of the computer readable medium / device 700.

[0091] The above description is presented to enable any person skilled in the art to make and use the various aspects and examples, and is provided in the context of a specific application and its requirements. Various modifications to the disclosed aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects and applications without departing from the spirit and scope of the present disclosure. Therefore, the aspects described herein are not limited to the aspects shown, but are to be consistent with the widest scope consistent with the principles and features disclosed herein.

[0092] Furthermore, the above descriptions of various aspects have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the aspects described herein to the disclosed forms. Therefore, many modifications and variations will be apparent to those skilled in the art. Additionally, the above disclosure is not intended to limit the aspects described herein. The scope of the aspects described herein is defined by the appended claims.

Claims

1. A method comprising: A registration process for monitoring the corresponding address range is performed, wherein the registration process includes: receiving a first command from an application to monitor a first address range in the kernel; registering the first address range in the kernel; creating a monitoring status window in the kernel, the monitoring status window indicating that the first address range is valid; and Providing the application with read-only access to the monitoring status window; detecting, in the kernel, a change associated with a memory mapping for a second address range based on a previous state of a mapping of virtual addresses to physical addresses; updating the monitoring status window by invalidating an address range overlapping with the second address range; and In response to the first address range being valid, the registration process is bypassed for the first address range.

2. The method according to claim 1, wherein: The registration process further includes: The first command includes a cookie generated by the application as an identifier of the command; storing the first address range, an index of an element in a second data structure of the kernel, and the cookie in an entry in a first data structure of the kernel; allocating the element in the second data structure, the element comprising a unique number generated for the element and a state set to a valid state; returning the index and the unique number to a cache in user space; and The index and the unique number are stored in a cache entry for the first address range.

3. The method according to claim 2, in, Updating the monitoring status window includes determining the address range that overlaps with the second address range by searching the first data structure.

4. The method according to claim 2, further comprising: determining whether to bypass or perform the registration process for the first address range based on the index and the unique number in the cache entry; Retrieving an element corresponding to the index by searching the second data structure based on the index and the unique number in the cache entry of the first address range; performing a comparison between the unique number in the cache entry and the unique number in the retrieved element; determining, based on the comparing, that the unique number in the cache entry matches the unique number in the retrieved element; In response to the state of the retrieved element being set to the valid state, determining that the first address range is valid and bypassing the registration process for the first address range; as well as In response to the state of the acquired element being set to an invalid state, determining that the first address range is invalid and performing the registration process for the first address range.

5. The method according to claim 2, further comprising: receiving a second command to perform a deregistration process, the second command including the first address range and a second cookie generated by the application as an identifier of the second command; as well as Responsive to the second cookie matching the cookie in the entry, removing the entry associated with the first address range from the first data structure.

6. The method according to claim 1, wherein: In response to detecting the change, the method further comprises: identifying in the first data structure the address range that overlaps with the second address range; In the elements of the second data structure corresponding to the identified address range, setting the corresponding state to an invalid state; and Entries corresponding to the identified address range are removed from the first data structure.

7. The method according to claim 1, wherein: Detecting the change comprises: Notification of the change associated with the memory mapping of the second address range is received from a memory management system of the kernel.

8. The method according to claim 1, wherein: After detecting the change, the method further comprises: A record is posted to an event queue invalidating the address range that overlaps with the second address range.

9. The method according to claim 1, further comprising: Providing the application with read-only access to a status window of the kernel, the status window including statistical information related to at least one of: The number of event registrations; An invalid quantity was processed; or Information about the occupancy of the event queue.

10. A computer system comprising: processor; as well as A storage device storing instructions for: A registration process for monitoring the corresponding address range is performed, wherein the registration process includes: registering the first address range in a registration database of the kernel in response to a request from an application; and indicating that the first address range is valid in a monitoring status window, the monitoring status window being a read-only data structure for the application; determining whether to bypass the registration process for the first address range based on a command to reuse the first address range; responsive to the first address range being valid in the monitoring state window, bypassing the registration process for the first address range; receiving notification of a change in a virtual-to-physical memory mapping associated with a second address range; and An address range overlapping with the second address range is invalidated in the monitoring status window.

11. The computer system according to claim 10, wherein: The registration process further includes: receiving a first command from the application to monitor the first address range in the kernel, the first command including a cookie generated by the application as an identifier of the command; storing the first address range, an index of an element in a second data structure of the kernel, and the cookie in an entry in a first data structure of the kernel; allocating the element in the second data structure, the element comprising a unique number generated for the element and a state set to a valid state; returning the index and the unique number to a cache in user space; and The index and the unique number are stored in a cache entry for the first address range.

12. The computer system of claim 11, the instructions further to, before invalidating the address range that overlaps with the second address range: By searching the first data structure, the address range that overlaps with the second address range is identified.

13. The computer system of claim 11, determining whether to bypass the registration process for the first address range comprises: determining whether to bypass or perform the registration process for the first address range based on the index and the unique number in the cache entry; Retrieving an element corresponding to the index by searching the second data structure based on the index and the unique number in the cache entry of the first address range; determining that the unique number in the cache entry matches the unique number in the retrieved element; In response to the state of the retrieved element being set to the valid state, determining that the first address range is valid and bypassing the registration process for the first address range; as well as In response to the state of the acquired element being set to an invalid state, determining that the first address range is invalid and performing the registration process for the first address range.

14. The computer system of claim 11, wherein the instructions are further configured to: receiving a second command to perform a deregistration process, the second command including the first address range and a second cookie generated by the application as an identifier of the second command; and Responsive to the second cookie matching the cookie in the entry, removing the entry associated with the first address range from the first data structure.

15. The computer system of claim 10, the instructions further operable to, in response to receiving the notification of the change: identifying in the first data structure the address range that overlaps with the second address range; In the elements of the second data structure corresponding to the identified address range, setting the corresponding state to an invalid state; and Entries corresponding to the identified address range are removed from the first data structure.

16. The computer system of claim 10, said instructions further being operable to, upon receiving said notification of said change: An event is posted to an event queue, the event indicating that the corresponding state is set to the invalid state in the element in the second data structure corresponding to the identified address range.

17. The computer system of claim 10, wherein the instructions are further configured to: Displaying a status window on a screen of a device associated with the application, the status window including statistical information related to at least one of: The number of event registrations; An invalid quantity was processed; or Information about the occupancy of the event queue.

18. A non-transitory computer-readable storage medium storing instructions for: A registration process for monitoring the corresponding address range is performed, the registration process comprising: receiving a first command from an application to register a first address range in a kernel, the first command including a cookie generated by the application identifying the command; registering the first address range in the kernel in response to the first command; Setting the first address range to a valid state in a monitoring status window in the kernel; as well as Providing the application with read-only access to the monitoring status window; determining whether to bypass the registration process for the first address range based on a command to reuse the first address range; as well as In response to the first address range being valid in the monitoring status window, bypassing the registration process for the first address range.

19. The non-transitory computer-readable storage medium of claim 18, The registration process further includes: generating a unique number corresponding to the first address range; storing the unique number in an element of the first address range in the monitoring status window; Returning the unique number to a cache in user space; as well as Wherein, determining whether to bypass the registration process for the first address range is based on: said unique number in said cache; the unique number stored in the element in the monitoring status window; and The state of the element in the monitoring window.

20. The non-transitory computer-readable storage medium of claim 18, the instructions further configured to: detecting, in the kernel, a change associated with a memory mapping for a second address range based on a notification message from a memory management subsystem of the kernel; identifying, in the registration database, an entry corresponding to an address range that overlaps with the second address range; deleting the identified entry from the registration database; as well as In the monitoring status window, an element having an address range overlapping with the second address range is invalidated by invalidating the corresponding status of the corresponding element.

Images