An operating system memory swapping mechanism to reduce memory page IO operations for delay-sensitive applications

Abstract

The application discloses a kind of operating system memory page mechanism for reducing the memory page IO operation of delay-sensitive application, specifically includes the following steps: one, constructs system application type / priority assessment model;Two, determine the process to which physical page frame belongs by physical page frame reverse mapping;Three, register two kinds of page recovery strategies for delay-sensitive application (high priority) and other application (low priority) respectively;Four, distinguish the process type / priority of page, when page is recycled, compress the page from delay-sensitive application in memory;The page from other application is swapped out to disk.This method monitors the page of swap-out system, and determines the priority of the process to which the page belongs, can guarantee delay-sensitive / high-priority application page as much as possible to save in memory, greatly reduces the exchange I / O of this kind of application page, so as to realize the improvement of system as a whole, especially the quality of service of delay-sensitive application.

Description

Technical fields:

[0001] This invention relates to a memory paging mechanism for operating systems (OS), and more particularly to an operating system memory paging mechanism that reduces memory page I / O operations of latency-sensitive applications, thereby significantly improving their Quality of Service (QoS). Background technology:

[0002] With the rapid development of computer technology, modern large-scale computer systems typically feature large-capacity Dynamic Random Access Memory (DRAM) and high-performance storage devices (such as SSDs and NVMe). These hardware configurations continuously enhance the computing and storage capabilities of current computer systems, enabling them to run numerous application processes simultaneously. Based on their varying quality-of-service (QoS) requirements, these applications can be categorized into latency-critical (LC) applications and other applications. Latency-critical applications generally have higher priority, emphasizing immediate response; other applications typically have lower priority, running as background or batch processes. However, a significant difference in transmission rates between main memory and storage devices severely limits the performance of computer systems, particularly impacting the QoS of latency-critical applications. To bridge this performance gap, employing efficient mechanisms to store data in main memory, thereby minimizing disk I / O and improving the QoS of latency-critical applications, is a wise approach.

[0003] Modern computer systems, especially cloud servers, are equipped with large-capacity main memory and a central processing unit (CPU) with numerous cores, enabling them to run a large number of application processes. However, it's important to note that main memory capacity is not unlimited. When memory pressure arises, pages in main memory will be swapped to storage devices; when swapped-out pages are used again, the system will swap them back from storage devices to main memory. These two processes are called page swapping out and page swapping in, respectively. Applications running in the operating system mainly fall into two categories: 1. Latency-sensitive applications: These applications emphasize immediate response to requests. Therefore, pages for these applications need to reside in memory as much as possible to avoid being swapped out to disk, minimizing application response latency. 2. Other applications: These applications typically run as background processes or batch tasks and are not sensitive to latency. Therefore, swapping pages for these applications out of disk has a limited impact on application performance.

[0004] When the operating system experiences high memory pressure, it needs to invoke the page reclamation process to release pages until the number of available pages reaches the high watermark defined by the operating system, meaning there are enough memory pages available for allocation. For example, in Linux, kswapd can scan process page tables and attempt to swap out some cold / inactive pages. However, when the swapped-out memory pages are accessed again, the operating system triggers a page fault exception and swaps these pages from storage devices into memory. This results in disk I / O, which inevitably leads to performance loss, especially for latency-sensitive applications, where the performance degradation is more pronounced. The greater the system's memory pressure, the more pages are swapped in and out, and the more frequent the disk I / O becomes, causing a sharp decline in the service quality of latency-sensitive applications, even rendering them unusable.

[0005] The following section will first introduce the page swapping algorithms used in existing operating systems, and then analyze the problems existing in the current page swapping through experiments.

[0006] Modern operating systems typically use an LRU-based page swapping algorithm. Taking Linux as an example, the memory management module uses two linked lists based on the LRU algorithm to organize pages. These two lists are called the active list and the inactive list, which together constitute the hot / cold page classification mechanism in the Linux memory management module. The active list contains all active pages (i.e., hot pages) of all processes, while the inactive list contains inactive pages (i.e., cold pages) that may be reclaimed or swapped to storage devices. The operating system determines the hot / cold status of pages by monitoring the access bit in the Page Entrance Table (PTE) and performs page promotion and demotion operations accordingly. When the access bit in the PTE is 1 (1 indicates that the page has been accessed during the sampling period), the operating system considers the current page a hot page and keeps it in the active list or promotes it from the inactive list. When the access bit in the PTE is 0 (0 indicates that the page has not been accessed during the sampling period), the operating system considers the current page a cold page and demotes it to the inactive list or swaps it out of the inactive list. It can be observed that the page swapping algorithm in the kernel is a typical two-chance algorithm, which can identify page attributes (i.e., hot and cold pages) to a certain extent.

[0007] Specifically, the page swapping mechanism will be triggered when an application requests more memory than the system's remaining memory or when memory pressure reaches the operating system's preset threshold. First, the kernel will calculate the number of pages that need to be scanned based on the parameter `nr`, where `nr` is determined by the following formula:

[0008] nr = len(list) >> p

[0009] Here, p represents the priority of the list, and the len() function can obtain the length of the list. Then, the kernel will scan the inactive list, use the reverse mapping to look up the page table entry of the corresponding page in the page table. When the access bit of the page table entry is 0, the page is swapped out; when the access bit of the page table entry is 1, the page is promoted to the active list. After that, since the ratio between the active list and the inactive list is 1.5, the number of pages m that need to be demoted from the active list will be calculated based on the length of the current inactive list. Finally, the active list is scanned based on the calculated value m, and the reverse mapping is used to look up the page table entry of the corresponding page in the page table. When the access bit of the page table entry is 0, the page is demoted; when the access bit of the page table entry is 1, the page is kept in the active list.

[0010] Meanwhile, modern operating systems typically maintain a memory pool between the LRU (Least Recently Used) reclaim queue for physical page frames and the hard disk, such as the swap cache in Linux. When a page swapping operation occurs, pages in the LRU queue that are to be swapped out are first moved to the swap cache. Then, at the appropriate time, in a cluster-based manner, through system I / O operations, the pages are evicted from memory and placed into the hard disk's swap area. The two LRU queues mentioned above manage pages for all processes without distinguishing between processes from which they originate. For example, in a specific Linux server, we have found that pages from latency-sensitive applications and pages from other applications both appear in the swap cache. The system treats pages from latency-sensitive applications and pages from other applications equally, treating them indiscriminately as candidates for swapping out of memory. In other words, these pages are swapped out of memory with equal probability. Therefore, in practice, we often find that existing operating systems blindly swap out pages from latency-sensitive applications while keeping pages belonging to other applications in memory, leading to a severe degradation in the quality of service for latency-sensitive applications.

[0011] In a typical cloud server, latency-sensitive services and other services coexist. However, we observed that the existing memory swapping mechanisms in modern operating systems (such as Linux and FreeBSD) cannot utilize the application characteristics of the process to which a page belongs (latency-sensitive applications or other applications). The existing system often blindly swaps out pages belonging to latency-sensitive applications, which are more sensitive to I / O operations. Meanwhile, pages belonging to other applications remain in memory, but these applications are not sensitive to page swapping I / O operations. In short, the existing page swapping operations lead to a significant degradation in the service quality of latency-sensitive applications. To further investigate this phenomenon, we ran a mixed workload, including latency-sensitive applications and other applications, simultaneously on a typical cloud server with 128GB of DDR4 memory. The latency-sensitive application was Redis (40GB), and other applications included Fluidanimate (5 threads, 20GB) and Streamcluster (10 threads, 10GB). In the tests, we used the VMswap tool to obtain the page swapping in / out status of various applications in the proc file system. We used the 99th percentile latency data as the standard for measuring the service quality of the Redis application. We ran a mixed load test for 1600 seconds. During the experiment, we found that in the initial 0-500 seconds of system operation, the system memory pressure was low, and operating system swapping operations were infrequent. During this phase, Redis response latency was low and very stable, indicating acceptable application quality of service. After 500 seconds, Redis memory usage increased, and the operating system began swapping memory pages (including pages from latency-sensitive applications and pages from other applications) to disk. As mentioned above, existing swapping operations indiscriminately swapped out pages from applications with varying quality of service requirements. Latency-sensitive applications are more sensitive to I / O-generating swaps, so extra care should be taken when swapping these pages. When these swapped-out pages are needed again, the operating system kernel has to re-migrate the pages from disk back into memory. In this experiment, the Redis service was blocked during this process until the operating system finished loading the pages into memory. Therefore, we can clearly observe a dramatic increase in Redis service response latency, with the 99th percentile response latency increasing from 0.15 seconds to 1.2 seconds.

[0012] As described above, we find that existing operating system swapping operations cannot distinguish between pages that need to be swapped out as belonging to latency-sensitive applications (high priority) or other applications (low priority). This results in some pages belonging to latency-sensitive applications being swapped out to disk. Such swapping operations cause a significant drop in the service quality of latency-sensitive applications, thereby affecting the overall system performance. Summary of the Invention:

[0013] To address the problems of the aforementioned methods, this paper proposes an operating system memory paging mechanism to reduce memory page I / O operations for latency-sensitive applications. This mechanism aims to retain pages of latency-sensitive applications in memory as much as possible, reducing unnecessary I / O from memory to disk and significantly improving their service quality, thereby further enhancing overall system performance. During operation, this method first distinguishes between different types of applications, namely, latency-sensitive applications and other applications. Then, during page swapping, this method utilizes reverse mapping to differentiate between different types of pages in the system's swap cache and determine their respective applications. Finally, based on the page type, this method compresses pages of latency-sensitive applications into memory, ensuring that these pages reside in memory as much as possible; pages of other applications are directly swapped out to the disk swap area. Compared to existing methods in operating systems (such as Linux), this method considers the specific characteristics of the application to which the page belongs during page swapping, enabling more detailed page differentiation and retaining pages of latency-sensitive applications in memory. This avoids frequent blocking of latency-sensitive applications due to page swapping operations, thus improving their service quality. Meanwhile, other applications are relatively insensitive to operating system I / O operations, thus the performance impact on these applications is limited. Overall, this method can effectively improve system performance.

[0014] Specifically, this method consists of three parts and operates in a pipeline manner. (1) This method designs a classifier to distinguish application types, used to differentiate between latency-sensitive applications (high priority) and other applications (low priority). (2) This method designs a monitor in the operating system swap cache to distinguish the application to which a page belongs, used to determine which application the page belongs to. (3) This method designs page reclamation strategies for latency-sensitive applications and page reclamation strategies for other low-priority applications. For pages of other low-priority applications, they are directly swapped out to the disk swap area; while for pages of latency-sensitive applications, this method sets up an additional compressed cache, thereby keeping pages of latency-sensitive applications in memory as much as possible.

[0015] The working process of each component is as follows:

[0016] I. Application Type Classifier

[0017] 1. The application type classifier distinguishes the large number of applications running in the operating system and runs within the operating system kernel;

[0018] 2. The system primarily contains two types of applications: latency-sensitive applications and other applications. The application type classifier mainly monitors the Process Control Block (PCB) `task_struct` and obtains process priorities. After obtaining the PCB, it determines the page reclamation strategy based on the static priority `static_prio` (a value greater than or equal to 100 and less than or equal to 139). A higher static priority corresponds to a higher process priority. Latency-sensitive applications typically have higher priorities in the system. Therefore, in the classifier, processes with a static priority greater than or equal to 100 and less than or equal to 120 are classified as latency-sensitive applications (high priority); processes with a static priority greater than or equal to 121 and less than or equal to 139 are classified as other applications (low priority). It should be noted that the priority threshold used to classify latency-sensitive applications and other applications using static priority can be adjusted by the user.

[0019] 2. By using an application type classifier, the operating system can more accurately classify the numerous applications running in the system, separating the pages of latency-sensitive applications from those of other applications. This allows the pages of latency-sensitive applications to be compressed into memory during subsequent recycling, while the pages of other applications are swapped out to the disk swap area.

[0020] II. Page Monitor

[0021] 1. The page monitor is used in the swap cache to monitor pages that are about to be swapped from memory to disk, in order to determine which application the page belongs to. It also runs in the operating system kernel.

[0022] 2. Based on the application type classifier, pages in the system can also be classified into two types: pages for latency-sensitive applications and pages for other applications. These two types of pages are mixed in the system's swap cache. Before a page is swapped out, the page monitor obtains the process control block of the process to which the page belongs through the reverse mapping of physical page frames, determines the application type of the page based on the static priority of the process (static_prio), and during the subsequent garbage collection process, compresses pages for latency-sensitive applications in memory while swapping out pages for other applications to the disk swap area.

[0023] III. Page recycling strategy.

[0024] 1. The page recycling strategy of this invention is mainly divided into a recycling strategy for latency-sensitive application pages and a recycling strategy for other application pages. Both page recycling strategies are registered with the frontswap interface of the swap cache backend, and the corresponding page recycling strategy is selected according to the process priority obtained by the page monitor.

[0025] 2. The page reclamation strategy for other applications is consistent with the existing mainstream Linux reclamation strategy, which directly swaps the pages of other applications from the swap cache in memory to the swap area on the disk.

[0026] 3. This invention innovatively proposes a page reclamation strategy for latency-sensitive applications. This strategy is designed for latency-sensitive applications based on two main considerations. First, latency-sensitive applications are more sensitive to system swapping operations. Frequent swapping and I / O operations between memory and disk negatively impact the service quality of applications. Therefore, pages of latency-sensitive applications should be kept in memory as much as possible. Second, when the system performs swapping operations and begins reclamation of pages, it indicates high memory pressure, and the operating system needs to release free memory for running applications, especially latency-sensitive applications. Utilizing zswap in Linux, this invention sets up a compressed cache in system memory for pages of latency-sensitive applications. The compressed cache size defaults to 10% of the total system memory and can be adjusted by the user. The compressed cache uses the zbud page allocator, which can store two compressed pages in a single physical page frame. When the operating system begins reclamation, based on the page monitor results, the system compresses pages belonging to latency-sensitive applications, freeing up system memory, and stores the compressed pages in the compressed cache in memory to avoid I / O operations by the operating system. When a latency-sensitive application needs these pages again, the system decompresses the pages from the compressed cache and swaps them into memory. This process completely avoids operating system I / O operations, effectively improving the response speed of latency-sensitive applications. It's important to note that the compressed cache has a limited capacity. Once the compressed cache is exhausted, the latency-sensitive application's page reclamation strategy will decompress the oldest compressed pages in the cache and swap them out to disk to make room for newly compressed pages. The compressed cache is only used by latency-sensitive / high-priority applications. Other application pages are handled through the original page reclamation process. Attached image description:

[0027] Figure 1 This is a flowchart of the operating system memory paging mechanism for reducing memory page I / O operations of latency-sensitive applications, as proposed in this invention.

[0028] Figure 2 This is a schematic diagram illustrating the adverse effects of existing Linux page reclamation strategies on the service quality of latency-sensitive applications, as detected by this invention.

[0029] Figure 3 This is a schematic diagram illustrating the reverse mapping of two types of pages by the page monitor of the present invention.

[0030] Figure 4 This invention relates to a strategy for recycling latency-sensitive applications and other application pages. Specific implementation methods:

[0031] (with reference to the attached figures) Figures 1-4 This will be described in further detail below.

[0032] like Figure 1 , Figure 2 , Figure 3 and Figure 4As shown, this method mainly consists of two strategies: a recycling strategy for latency-sensitive application pages and a recycling strategy for other application pages. These strategies address the recycling process for latency-sensitive application pages and other application pages, respectively. This method uses the reverse mapping in the page monitor to obtain the process control block corresponding to the page, and further determines the page type to be recycled based on the classification results of the application type classifier. The recycling process for other application pages is consistent with existing Linux system recycling strategies: pages are placed from the system LRU queue into the memory swap cache and written to the disk swap area at an appropriate time. When other applications need these pages again, the operating system retrieves them from the disk swap area back into memory. During this process, system I / O is unavoidable. This method innovatively proposes a recycling strategy specifically for latency-sensitive application pages. By using the zswap interface in Linux, this method sets up an additional page compression cache in memory. This cache stores pages selected for recycling by the system from latency-sensitive applications and interacts with the swap cache and disk to complete the swap-in and swap-out operations of latency-sensitive application pages. In the compressed cache, using zbud, this method can store two compressed pages within a single physical page frame, saving system memory space when the operating system is under heavy memory pressure. Currently, the compressed cache is set to 10% of the total system memory. When system memory pressure is low, compressed pages can be completely stored in the compressed cache. In this case, for latency-sensitive applications, all pages are stored in memory, and no disk I / O is generated compared to the original method. However, when memory pressure is high, due to the limited capacity of the compressed cache, not all compressed pages can be stored in the compressed cache. In this case, the system will decompress the oldest page in the compressed cache and swap it out to disk to make room for the most recently swapped-out page. Based on the principle of spatiotemporal locality of reference, this ensures that the most likely pages to be used are kept in memory as much as possible. According to the above process description, there are two different cases of page swapping for latency-sensitive applications. First, the page is swapped from the disk swap area into memory, which is consistent with the page swapping in the existing method, that is, the page is placed in the swap cache after being placed from the disk swap area, and then further swapped into memory. The newly configured compressed cache in this method decompresses the page and places it into the swap cache when the page is swapped out, and then swaps it into memory. During this process, the swapping of latency-sensitive application pages avoids disk I / O, thereby improving its service quality.

[0033] The above method is implemented in an Ubuntu Linux distribution with kernel version 5.10. This method uses the `frontswap` module—an interface in Linux that stores swap pages on the swap device. Two policies are registered in its backend, namely the two page reclamation policies mentioned above. After a page is placed into the swap cache by the swap thread, this method uses a reverse mapping similar to that used in `try_to_unmap()` to obtain the priority of the process corresponding to the page. In the system, there are two different types of pages (anonymous pages and file pages), and their reverse mapping paths are different. As shown in the figure, the reverse mapping path for anonymous pages is `page—anon_vma_chain—anon_vma—vma_area_struct—mm_struct—task_struct`. The reverse mapping path for file pages is `page—address_space—mm_struct—task_struct`. The `task_struct` data structure is the process control block we need. In the `__frontswap_store()` function, this method executes the above reverse mapping to reclaim pages according to different reclamation policies. Finally, this method uses `zswap` to manage compressed pages and uses the `crypto comp` compression / decompression interface to interact with the compression cache.

Claims

1. An operating system memory paging method for reducing memory page I / O operations in latency-sensitive applications, characterized in that, The method includes a pipeline approach that utilizes the following three components: (1) designing a classifier that distinguishes between application types, specifically high-priority latency-sensitive applications and low-priority applications; (2) Design a monitor in the operating system swap buffer to distinguish the application to which the page belongs, in order to determine whether the page belongs to a high-priority latency-sensitive application page or a low-priority application page; (3) Design a recycling strategy for high-priority latency-sensitive application pages and a recycling strategy for low-priority application pages. For pages of low-priority applications, they are swapped out to the disk swap area; while for pages of high-priority latency-sensitive applications, an additional compressed cache is set up to keep pages of high-priority latency-sensitive applications in memory as much as possible. The specific design and implementation process of the page recycling strategy includes the following steps: Step 1: The page recycling strategy is divided into a high-priority latency-sensitive application page recycling strategy and a low-priority application page recycling strategy. Both page recycling strategies are registered with the frontswap interface of the swap cache backend, and the corresponding page recycling strategy is selected according to the process priority obtained by the page monitor. Step 2: The low-priority application page reclamation strategy is consistent with the Linux reclamation strategy, which directly swaps the pages of low-priority applications from the swap cache in memory to the swap area on the disk. Step 3: High-Priority Latency-Sensitive Application Page Reclamation Strategy. For high-priority latency-sensitive applications, a compressed cache is set up in system memory using Linux's zswap. The compressed cache size is 10% of the total system memory by default and can be adjusted by the user. The compressed cache uses the zbud page allocator, which stores two compressed pages within a single physical page frame. When the operating system begins reclaiming pages, based on the page monitor's results, the system compresses pages belonging to high-priority latency-sensitive applications to free up system memory and stores the compressed pages in the compressed cache in memory. The compressed cache is stored in memory to avoid operating system I / O operations. When a high-priority latency-sensitive application needs these pages again, the system decompresses the pages from the compressed cache and swaps them into memory. In this process, operating system I / O operations are completely avoided, effectively improving the response speed of high-priority latency-sensitive applications. The compressed cache has a limited capacity. After the compressed cache is exhausted, the high-priority latency-sensitive application page reclamation strategy will decompress the oldest compressed pages in the compressed cache and swap them out to disk to make room for newly compressed pages. The compressed cache is only used by high-priority latency-sensitive applications, while low-priority application pages are still processed through the original page reclamation process.

2. The operating system memory paging method for reducing memory page I / O operations in latency-sensitive applications according to claim 1, characterized in that, The specific design and execution process of the application type classifier includes the following steps: Step 1: The application type classifier distinguishes the large number of applications running in the operating system and runs in the operating system kernel. Step 2: There are two types of applications in the system: high-priority latency-sensitive applications and low-priority applications. The application type classifier monitors the process control block (task_struct) and obtains the process priority. After obtaining the process control block, it determines the page reclamation strategy based on the static priority (static_prio). The static priority value (static_prio) is greater than or equal to 100 and less than or equal to 139, where a higher static priority indicates a higher process priority. Latency-sensitive applications have higher priority in the system. Therefore, in the classifier, processes with a static priority greater than or equal to 100 and less than or equal to 120 are classified as low-priority applications; processes with a static priority greater than or equal to 121 and less than or equal to 139 are classified as high-priority latency-sensitive applications. The priority threshold for classifying high-priority latency-sensitive applications and low-priority applications using static priority is adjusted by the user. Step 3: Using an application type classifier, the operating system distinguishes between high-priority latency-sensitive application pages and low-priority application pages. This allows the high-priority latency-sensitive application pages to be compressed into memory during subsequent garbage collection, while the low-priority application pages are swapped out to the disk swap area.

3. The operating system memory paging method for reducing memory page I / O operations in latency-sensitive applications according to claim 1, characterized in that, The specific design and execution process of the monitor in the operating system's swap cache that distinguishes the application to which a page belongs includes the following steps: Step 1: This monitor is used in the swap cache to monitor pages that are about to be swapped from memory to disk, and it also runs in the operating system kernel. Step 2: Based on the application type classifier results, pages in the system are also classified into high-priority pages for latency-sensitive applications and low-priority pages for applications. These two types of pages are mixed in the system's swap cache. Before a page is swapped out, the page monitor obtains the process control block of the process to which the page belongs through the reverse mapping of physical page frames, and determines the type of application to which the page belongs based on the static priority (static_prio). In the subsequent recycling process, high-priority pages for latency-sensitive applications are compressed in memory, while low-priority pages for applications are swapped out to the disk swap area.

Images