Static tracking point based file cache state tracking method, system, and product

Abstract

The application discloses a file cache state tracking method, system and product based on static tracking points. The method comprises the following steps: in response to different trigger operations of a virtual interface, determining a scanning range of a file cache in a Linux kernel; based on the scanning range, scanning file cache data in the Linux kernel, and triggering a plurality of static tracking points registered in the Linux kernel to acquire the file cache data; using an extended filtering technology to receive the file cache data acquired by the plurality of static tracking points, and processing the file cache data to determine a cache application situation of a target file. The method uses the static tracking points registered in the Linux kernel in advance to acquire the file cache data, and combines the extended filtering technology to process the file cache data, so that real-time tracking of a file cache state change is realized, thereby reducing tracking overhead and improving tracking precision.

Description

Technical Field

[0001] This application relates to the field of data management in the Linux operating system kernel, specifically to a file cache state tracking method, system, and product based on static trace points. Background Technology

[0002] Currently, in the Linux operating system, memory resources can be categorized into four types based on their usage: process-private memory, file-mapped memory, kernel-used memory, and various caches. In production environments, Linux operating systems running large database services allocate a significant amount of physical memory as file cache.

[0003] However, existing technologies for tracking Linux operating system file caches have three limitations: lack of dynamism, uncontrollable overhead, and insufficient accuracy. This makes it impossible for operations and maintenance personnel to accurately quantify the cache usage of individual files, thereby affecting memory usage optimization and service quality assurance. Summary of the Invention

[0004] In view of the above-mentioned defects or deficiencies in the existing technology, it is desirable to provide a file cache state tracking method, system and product based on static tracking points. This method uses static tracking points pre-registered in the Linux kernel to acquire file cache data and combines extended filtering technology to process the file cache data, so as to realize real-time tracking of file cache state changes, thereby reducing tracking overhead and improving tracking accuracy.

[0005] In a first aspect, the present invention provides a file cache state tracking method based on static tracking points, the method comprising:

[0006] In response to different triggering operations on the virtual interface, determine the scan range of the file cache in the Linux kernel;

[0007] The file cache data in the Linux kernel is scanned based on the scan range, and multiple static trace points registered in the Linux kernel are triggered to obtain the file cache data.

[0008] Extended filtering technology is used to receive file cache data from multiple static tracking points, and the file cache data is processed to determine the cache application status of the target file.

[0009] In one possible implementation, the scan range of the file cache in the Linux kernel is determined in response to different triggering operations on the virtual interface, including:

[0010] Receive and parse the trigger operation on the virtual interface to determine the file type of the target file;

[0011] Determine the scan range of the target file's corresponding file cache based on the file type.

[0012] In one possible implementation, the correspondence between the triggering operation and the scanning range includes:

[0013] When a trigger command is written to the system file to be traversed, the scan scope is determined to be the page cache of all files in the target file system;

[0014] When a trigger instruction is written to the target file to be traversed, the scan range is determined to be the page cache of the target file;

[0015] When writing parameter addresses to the target memory file, the scan range is determined to be the number of physical pages mapped to the target physical address range.

[0016] In one possible implementation, file cache data in the Linux kernel is scanned based on a scan range, and multiple static tracing points are triggered to retrieve the file cache data, including:

[0017] Activate multiple static trace points and determine the kernel scan function used to scan file cache data based on the scan range;

[0018] The kernel scanning function is used to obtain the file cache data of the target file within the scanning range, and this data is then obtained from multiple activated static tracking points.

[0019] In one possible implementation, the registration process for multiple static tracking points includes:

[0020] Define the parameter prototype of the static tracking point in the Linux kernel;

[0021] A parameter list for the static tracking point is generated based on the parameter prototype, and the record field of the static tracking point is configured according to the metadata structure of the file cache page; the parameter list is used to represent the correspondence between different parameter prototypes and the data to be acquired;

[0022] Based on the parameter list, the data to be acquired corresponding to the parameter prototype is mapped to the record field of the static tracking point, and a text formatting output rule is generated according to the record field that conforms to the preset data structure.

[0023] In one possible implementation, the multiple static tracking points include at least: a directory entry metadata collection point dump_inode, a physical page frame status tracking point dump_page, a virtual address range page count tracking point dump_pagecache_range, and an interface file operation monitoring point dump_header.

[0024] In one possible implementation, the kernel scanning function includes at least the dump_fs_pagecache function and the dump_pagecache function;

[0025] The dump_fs_pagecache function is used to scan the page cache of all files in the target file system.

[0026] In one possible implementation, extended filtering techniques are used to receive file cache data acquired from multiple static tracking points, including:

[0027] Multiple static tracking points transmit file cache data to the extended filtering user-space program via a circular buffer, where the extended filtering user-space program receives the data.

[0028] Secondly, a file cache state tracking system based on static tracking points is provided, the system comprising:

[0029] The first processing module is used to determine the scan range of the file cache in the Linux kernel in response to different triggering operations on the virtual interface;

[0030] The scanning module is used to scan the file cache data in the Linux kernel based on the scanning range and trigger multiple static trace points registered in the Linux kernel to obtain the file cache data;

[0031] The second processing module is used to receive file cache data obtained from multiple static tracking points using extended filtering technology, and to process the file cache data to determine the cache application status of the target file.

[0032] Thirdly, a computer program product is provided, which includes instructions that, when executed, perform the method described in any one of the first aspects.

[0033] Fourthly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method described in any one of the first aspects above.

[0034] Fifthly, a computer-readable storage medium is provided having a computer program stored thereon, characterized in that the program, when executed by a processor, implements the method described in any one of the first aspects above.

[0035] The file cache state tracking method, system, and product based on static trace points provided in this application offer a low-overhead time frame through pre-registered static trace points in the Linux kernel. These static trace points are then used to perform kernel-level scanning of the file cache data, enabling accurate data acquisition. Furthermore, extended filtering technology is used to flexibly process and control user-space data, achieving real-time tracking of file cache state changes. This reduces tracking overhead while improving tracking accuracy. Simultaneously, it enhances the transparency of file cache management in the Linux operating system, providing a precise basis for system performance optimization and resource scheduling. Attached Figure Description

[0036] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0037] Figure 1 This is a flowchart illustrating a file cache state tracking method based on static tracking points provided in an embodiment of this application.

[0038] Figure 2 This is a schematic diagram of the process of registering static tracking points provided in an embodiment of this application;

[0039] Figure 3 This is a schematic diagram illustrating the process of executing an eBPF program according to an embodiment of this application;

[0040] Figure 4 This is a flowchart illustrating a kernel scanning function execution method provided in an embodiment of this application;

[0041] Figure 5 This is a flowchart illustrating another kernel scanning function execution method provided in an embodiment of this application;

[0042] Figure 6 This is a schematic diagram of the process for obtaining file cache data provided in an embodiment of this application;

[0043] Figure 7 This is another flowchart illustrating the file cache state tracking method based on static tracking points provided in this application embodiment;

[0044] Figure 8 This is a block diagram of a file cache state tracking system based on static tracking points provided in an embodiment of this application;

[0045] Figure 9 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0046] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0047] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present application will now be described in detail with reference to the accompanying drawings and embodiments. Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The terms "first" and "second," etc., in the specification and claims of the embodiments of this application are used to distinguish different objects, not to describe a specific order of objects.

[0048] In one possible implementation, Figure 1 This is a flowchart illustrating a file cache state tracking method based on static tracking points provided in an embodiment of this application, such as... Figure 1 As shown, the method specifically includes the following steps:

[0049] Step S101: In response to different triggering operations on the virtual interface, determine the scan range of the file cache in the Linux kernel.

[0050] In one possible implementation, trigger operations can be received and parsed through a set virtual file system interface to dynamically control the file cache scan range; that is, the virtual file system interface can associate the interaction between user mode and kernel mode, so that the user can flexibly adjust the scanning behavior according to real-time needs.

[0051] The virtual file system interface is centrally located in the ` / sys / kernel / debug / tracing` directory, which mounts the `tracefs` pseudo-file system. Correspondingly, `tracefs` provides a specific virtual file system to allow users to obtain in-depth information about kernel behavior (e.g., file cache state) by viewing and manipulating specific files in that file system. Secondly, `tracefs` provides a non-intrusive way to monitor and analyze the Linux kernel; that is, user-space programs can complete all interactions through file read and write operations without modifying kernel code or using dedicated debugging tools.

[0052] For example, the file type of the target file can be determined based on the triggering operation of the virtual interface, so as to dynamically select the scan range of the file cache according to the file type.

[0053] Specifically, when the parsing result of the parameters passed to the above virtual interface (i.e., the execution attribute information) indicates that the target file type is a directory file, the walk-fs interface is identified as being triggered.

[0054] Optionally, when the parsing result of the parameters passed to the above virtual interface indicates that the target file type is a regular file, the walk-file interface is identified as being triggered.

[0055] For example, based on the identification operations of the different trigger interfaces mentioned above, the corresponding cache scan range can be determined.

[0056] Specifically, when a trigger instruction (i.e., identifying the trigger interface walk-fs) is written to the traversal system file, the scan scope is determined to be the page cache of all files in the target file system.

[0057] Correspondingly, by writing trigger commands to the file / sys / kernel / debug / tracing / object / mm / pages / walk-fs, the page cache of all files under the target file system can be scanned.

[0058] Optionally, when a trigger instruction (i.e., identifying the trigger interface walk-file) is written to the target file to be traversed, the scan range is determined to be the page cache of the target file.

[0059] By writing trigger commands to the file ` / sys / kernel / debug / tracing / object / mm / pages / walk-file`, the page cache of the target file can be scanned. That is,

[0060] Optionally, when writing parameter addresses to the target memory file, the scan range is determined to be the number of physical pages mapped to the target physical address range.

[0061] The number of physical pages mapped to a specified physical address range is scanned by writing the parameter address to the file / sys / kernel / debug / tracing / object / mm / pages / dump-range.

[0062] Step S102: Scan the file cache data in the Linux kernel based on the scan range, and trigger multiple static trace points registered in the Linux kernel to obtain the file cache data.

[0063] In one possible implementation, based on the scan range of the file cache determined in step S101, the metadata and state change information of the file cache can be captured by a set of static tracking points predefined in the Linux kernel; that is, the set of static tracking points can implant data acquisition hooks on the kernel critical path to achieve transparent monitoring of the internal state of the file cache.

[0064] For example, multiple static tracing points include at least: the directory entry metadata collection point dump_inode, the physical page frame status tracing point dump_page, the virtual address range page count tracing point dump_pagecache_range, and the interface file operation monitoring point dump_header.

[0065] For example, after activating the above-mentioned multiple static tracking points, the kernel scanning function for scanning file cache data can be determined based on the scan range obtained by parsing the virtual interface. The kernel scanning function can then be used to obtain the file cache data of the target file within the specified scan range, and the activated static tracking points can perform structured collection.

[0066] Specifically, the kernel scanning functions include at least the dump_fs_pagecache function and the dump_pagecache function; correspondingly, the dump_fs_pagecache function is used to scan the page cache of all files in the target file system, and the dump_pagecache function is used to scan the page cache of the target file.

[0067] Specifically, Figure 2 This is a schematic diagram of the process of registering static tracking points provided in the embodiments of this application, such as... Figure 2 As shown, the registration steps for multiple static tracking points specifically include:

[0068] Step S201: Define the parameter prototype of the static tracking point in the Linux kernel;

[0069] Correspondingly, a custom tracepoint static tracepoint prototype can be built in the Linux kernel to define the parameter prototype of the tracepoint static tracepoint based on the tracepoint static tracepoint prototype.

[0070] Step S202: Generate a parameter list for static tracking points based on the parameter prototype;

[0071] Correspondingly, the parameter list is used to characterize the correspondence between different parameter prototypes and the data to be acquired. That is, the parameter list can characterize the specific individual data that needs to be captured when using the parameter prototype, so that such data can be mainly captured during subsequent file scanning.

[0072] Step S203: Configure the record fields of static tracking points according to the metadata structure of the file cache page;

[0073] Step S204: Configure the record fields of static tracking points according to the metadata structure of the file cache page;

[0074] Step S205: Based on the parameter list, map the data to be acquired corresponding to the parameter prototype to the record field of the static tracking point;

[0075] Correspondingly, based on the aforementioned steps, a pointer to the corresponding data structure to be acquired is captured. The data to be acquired is dumped and saved as an _entry structure to realize the mapping from the prototype of the tracepoint static trace point parameter to the field of the tracepoint static trace point record, so as to dump and save the specific data content.

[0076] Step S206: Generate text formatting output rules based on record fields that conform to the preset data structure;

[0077] The preset data structure is the user-defined output rule, which enables the connection to different data receiving technologies when different preset data structures are met; the text formatting output rule corresponds to the Linux kernel event text formatting output rule.

[0078] Step S103: Receive file cache data obtained from multiple static tracking points using extended filtering technology, and process the file cache data to determine the cache application status of the target file.

[0079] In this embodiment, by combining eBPF technology (i.e., extended filtering technology) and data interaction with multiple set static tracking points, efficient interaction with the Linux kernel is achieved, thereby enabling efficient acquisition of data in the kernel to track file cache usage in the Linux operating system in real time.

[0080] In one possible implementation, when using eBPF technology to receive file cache data acquired from multiple static tracking points, the multiple static tracking points can transfer the file cache data to the extended filtering user-space program (i.e., the eBPF user-space program) through a circular buffer for reception by the eBPF user-space program.

[0081] The circular buffer can be a ringbuf circular buffer; correspondingly, the eBPF user-space program can filter the received file cache data and sort and output the filtered file cache data.

[0082] Specifically, Figure 3 This is a schematic diagram illustrating the process of executing an eBPF program according to an embodiment of this application, as shown below. Figure 3As shown, the specific execution steps of an eBPF program include:

[0083] Step S301: Load and verify the eBPF kernel-mode program;

[0084] Correspondingly, after verification by the Linux kernel, the eBPF kernel-mode program can be mounted to the tracepoint static trace point.

[0085] Step S302: Select the trigger interface based on the parameters passed in from the user mode;

[0086] Correspondingly, the file cache scan range in the Linux operating system can be determined based on the selected trigger interface.

[0087] Specifically, when the user-mode input parameter indicates that the target file is a directory file, step S3031 is executed; when the user-mode input parameter indicates that the target file is a regular file, step S3032 is executed.

[0088] Step S3031: Trigger the walk_fs interface;

[0089] Step S3032, trigger the walk_file interface;

[0090] Step S3041: Activate the kernel file cache scanner dump_fs_pagecache;

[0091] Step S3042: Activate the kernel file cache scanner dump_pagecache;

[0092] Step S305: During the file cache scan, file cache metadata is collected using custom-registered tracepoint static trace points;

[0093] Step S306: The collected data is transmitted to the eBPF user-space program through the ringbuf ring buffer;

[0094] Step S307: The eBPF user-space program receives file cache metadata;

[0095] Step S308: Filter the received file cache metadata and sort and output the filtered file cache data.

[0096] The file cache state tracking method based on static tracking points provided in this application provides a low-overhead time frame by pre-registering static tracking points in the Linux kernel, and uses static tracking points to perform kernel-level scanning of file cache data to achieve accurate data acquisition. Secondly, it uses extended filtering technology to flexibly process and control user-space data to achieve real-time tracking of file cache state changes, thereby reducing tracking overhead while improving tracking accuracy. At the same time, it improves the transparency of file cache management in the Linux operating system, providing accurate basis for system performance optimization and resource scheduling.

[0097] In another embodiment of this application, when the kernel scanning function is the dump_fs_pagecache function, an execution method for the kernel scanning function is also provided.

[0098] For example, Figure 4 This is a flowchart illustrating a kernel scanning function execution method provided in an embodiment of this application, as shown below. Figure 4 As shown, the method specifically includes the following steps:

[0099] Step S401: Obtain the target file system superblock sb, and sequentially obtain its associated read / write semaphore s_umount and spinlock s_inode_list_lock;

[0100] Step S402: Traverse the inode list s_inodes of the superblock;

[0101] Step S403: Obtain the filename and its metadata during the traversal process;

[0102] Correspondingly, a custom kernel function, dump_inode, can be executed to obtain the filename and its metadata.

[0103] Step S404: Determine if the file page cache count is 0;

[0104] Correspondingly, after obtaining the file metadata, the file page cache status can be determined. If the page cache count is 0, then step S402 is executed to traverse the next inode; otherwise, step S405 is executed.

[0105] Step S405: Scan the file's page cache;

[0106] Correspondingly, a custom kernel function dump_pagecahe can be executed to scan the file page cache; after the file page cache scan is completed, step S402 can be executed to perform the next round of traversal.

[0107] Step S406: After the traversal is complete, release the resources and exit the program;

[0108] Correspondingly, after the traversal of the linked list s_inodes is completed, the spinlock s_inode_list_lock and the read / write semaphore s_umount can be released in an orderly manner.

[0109] In another embodiment of this application, when the kernel scanning function is the dump_pagecache function, another way of executing the kernel scanning function is also provided.

[0110] For example, Figure 5 This is a flowchart illustrating another kernel scanning function execution method provided in an embodiment of this application, as shown below. Figure 5 As shown, the method specifically includes the following steps:

[0111] Step S501: Obtain the page cache radix tree i_pages of the target file;

[0112] Step S502: Traverse the file page cache radix tree i_pages and determine whether the page cache count is 0;

[0113] Correspondingly, if the page cache count is 0, then step S505 is executed; otherwise, step S503 is executed.

[0114] Step S503: Determine whether the cached page is a composite page;

[0115] Correspondingly, if the cached page is a composite page, then step S504 is executed; otherwise, step S502 is executed to traverse the next number node.

[0116] Step S504: Scan the last page of the composite page;

[0117] Correspondingly, after completing the scanning of the last page of the current composite page, step S502 can be executed to proceed to the next round of traversal.

[0118] Step S505: Release resources and exit radix tree traversal.

[0119] In another embodiment of this application, a specific method for obtaining file cache data is also provided.

[0120] For example, the process of obtaining the cached data of this file can be regarded as the execution process of the custom file cache scanning program provided in the embodiments of this application.

[0121] Correspondingly, Figure 6 This is a schematic diagram of the process for obtaining file cache data provided in an embodiment of this application, such as... Figure 6 As shown, the process specifically includes the following steps:

[0122] Step S601: Receive and parse the input parameters of the virtual interface, and open the target file based on the input parameters;

[0123] Correspondingly, if the target file fails to open, step S605 is executed to enter the failure handling process, and then the process ends and exits; otherwise, step S602 is executed.

[0124] Step S602: Activate the static tracepoint.

[0125] Correspondingly, if the activation of the static tracepoint fails, step S605 is executed to enter the failure handling process, and then the process ends and exits; otherwise, step S603 is executed.

[0126] Step S603: Determine the file type of the target file;

[0127] Correspondingly, if the file type is a directory file, then step S6041 is executed; if the file type is a regular file, then step S6042 is executed.

[0128] Step S6041: Identify the trigger interface walk-fs and execute the custom kernel function dump_fs_pagecache to scan the page cache of all files under the target file system;

[0129] In step S6042, the trigger interface walk_file is identified, and the custom kernel function dump_pagecache is executed to scan the page cache of the target file.

[0130] In another embodiment of this application, another implementation of the file cache state tracking method based on static tracking points is also provided.

[0131] For example, Figure 7 This is another flowchart illustrating the file cache state tracking method based on static tracking points provided in this application embodiment, as shown below. Figure 7 As shown, the method includes the following steps:

[0132] Step S701: Register predefined tracepoint static trace points in the Linux kernel to collect file cache metadata and status change information using tracepoint static trace points;

[0133] Step S702: Trigger and control the file cache scan range through the set virtual file system interface, and execute the corresponding kernel-level file cache scan program;

[0134] Correspondingly, the file cache scanner includes: kernel function dump_fs_pagecache, kernel function dump_pagecache, etc.

[0135] Step S703, combined with eBPF technology, enables efficient interaction with the Linux kernel to track the file cache usage of the Linux operating system in real time.

[0136] In another embodiment of this application, a file cache state tracking system based on static tracepoints is also provided, which enables the custom tracepoint static tracepoint, the custom kernel-level file cache scanner, and the eBPF program provided in this application to cooperate with each other.

[0137] For example, Figure 8 This is a block diagram of a file cache state tracking system based on static tracking points provided in an embodiment of this application, as shown below. Figure 8 As shown, the file cache state tracking system 800 based on static tracking points includes: a first processing module 801, a scanning module 802, and a second processing module 803, wherein...

[0138] The first processing module 801 is used to determine the scan range of the file cache in the Linux kernel in response to different triggering operations on the virtual interface;

[0139] The scanning module 802 is used to scan the file cache data in the Linux kernel based on the scanning range, and trigger multiple static trace points registered in the Linux kernel to obtain the file cache data;

[0140] The second processing module 803 is used to receive file cache data obtained from multiple static tracking points using extended filtering technology, and to process the file cache data to determine the cache application status of the target file.

[0141] The following is for reference. Figure 9 , Figure 9 A schematic diagram of a communication device suitable for implementing embodiments of this application is shown, such as... Figure 9 As shown, the communication device 900 includes a central processing unit (CPU) 901, which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 902 or a program loaded from a storage section 908 into a random access memory (RAM) 903. The RAM 903 also stores various programs and data required for the system's operating instructions. The CPU 901, ROM 902, and RAM 903 are interconnected via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0142] The following components are connected to the input / output (I / O) interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the input / output (I / O) interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

[0143] Specifically, according to embodiments of this application, the flowchart above refers to... Figures 1-7 Any of the described processes can be implemented as a computer software program. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program contains program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 909, and / or installed from removable medium 911. When the computer program is executed by central processing unit (CPU) 901, it performs the functions defined in the system of this application.

[0144] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium compatible with computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0145] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operational instructions of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two connected blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified functions or operational instructions, or using a combination of dedicated hardware and computer instructions.

[0146] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be housed in a processor; for example, a processor may be described as including a semantic extraction unit, a weight allocation unit, and a determination unit. The names of these units or modules do not necessarily constitute a limitation on the unit or module itself.

[0147] On the other hand, this application also provides a computer-readable storage medium, which may be included in the communication device described in the above embodiments, or may exist independently and not assembled into the communication device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the methods described in this application. For example, it may execute... Figures 1-7 Each step of any of the methods shown.

[0148] This application provides a computer program product including instructions that, when executed, cause the method described in this application to be performed. For example, it can execute... Figures 1-7 Each step of any of the methods shown.

[0149] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A file cache state tracking method based on static tracking points, characterized in that, The method includes: In response to different triggering operations on the virtual interface, determine the scan range of the file cache in the Linux kernel; The file cache data in the Linux kernel is scanned based on the scan range, and multiple static trace points registered in the Linux kernel are triggered to obtain the file cache data. The file cache data obtained from the multiple static tracking points is received using extended filtering technology, and the file cache data is processed to determine the cache application status of the target file; The process of determining the scan range of the file cache in the Linux kernel in response to different triggering operations on the virtual interface includes: The system receives and parses trigger operations on the virtual file system interface to determine the file type of the target file. The virtual file system interface is used to associate the interaction between user mode and kernel mode and is centrally located in the / sys / kernel / debug / tracing directory. Based on the file type, determine the scan range of the file cache corresponding to the target file; the correspondence between the triggering operation and the scan range includes: When a trigger command is written to the traversal system file, the scan range is determined to be the page cache of all files in the target file system; When a trigger instruction is written to the target file to be traversed, the scan range is determined to be the page cache of the target file; When writing parameter addresses to the target memory file, the scan range is determined to be the number of physical pages mapped to the target physical address range; The process of receiving file cache data obtained from the multiple static tracking points using extended filtering technology includes: The multiple static tracking points transmit the file cache data to the extended filtering user-space program via a circular buffer, where the extended filtering user-space program receives the data. The extended filtering user-space program then filters the received file cache data and sorts and outputs the filtered file cache data.

2. The file cache state tracking method based on static tracking points according to claim 1, characterized in that, The process of scanning the file cache data in the Linux kernel based on the scan range and triggering multiple static tracing points to acquire the file cache data includes: Activate the plurality of static tracking points, and determine the kernel scan function for scanning the file cache data based on the scan range; The kernel scanning function is used to obtain the file cache data of the target file within the scanning range, and this data is then obtained from multiple activated static tracking points.

3. The file cache state tracking method based on static tracking points according to claim 1, characterized in that, The registration process for the multiple static tracking points includes: Define the parameter prototype of the static tracking point in the Linux kernel; A parameter list for the static tracking point is generated based on the parameter prototype, and the record field of the static tracking point is configured according to the metadata structure of the file cache page; the parameter list is used to represent the correspondence between different parameter prototypes and the data to be acquired; Based on the parameter list, the data to be acquired corresponding to the parameter prototype is mapped to the record field of the static tracking point, and a text formatting output rule is generated according to the record field that conforms to the preset data structure.

4. The file cache state tracking method based on static tracking points according to claim 1 or 3, characterized in that, The multiple static tracking points include at least: the directory entry metadata collection point dump_inode, the physical page frame status tracking point dump_page, the virtual address range page count tracking point dump_pagecache_range, and the interface file operation monitoring point dump_header.

5. The file cache state tracking method based on static tracking points according to claim 2, characterized in that, The kernel scanning function includes at least the dump_fs_pagecache function and the dump_pagecache function; The dump_fs_pagecache function is used to scan the page cache of all files in the target file system.

6. A file cache state tracking system based on static tracking points, characterized in that, The system includes: The first processing module is used to determine the scan range of the file cache in the Linux kernel in response to different triggering operations on the virtual interface; The scanning module is used to scan file cache data in the Linux kernel based on the scanning range, and trigger multiple static tracking points registered in the Linux kernel to obtain the file cache data; The second processing module is used to receive file cache data obtained from the multiple static tracking points using extended filtering technology, and to process the file cache data to determine the cache application status of the target file. The process of determining the scan range of the file cache in the Linux kernel in response to different triggering operations on the virtual interface includes: The system receives and parses trigger operations on the virtual file system interface to determine the file type of the target file. The virtual file system interface is used to associate the interaction between user mode and kernel mode and is centrally located in the / sys / kernel / debug / tracing directory. Based on the file type, determine the scan range of the file cache corresponding to the target file; the correspondence between the triggering operation and the scan range includes: When a trigger command is written to the traversal system file, the scan range is determined to be the page cache of all files in the target file system; When a trigger instruction is written to the target file to be traversed, the scan range is determined to be the page cache of the target file; When writing parameter addresses to the target memory file, the scan range is determined to be the number of physical pages mapped to the target physical address range; The process of receiving file cache data obtained from the multiple static tracking points using extended filtering technology includes: The multiple static tracking points transmit the file cache data to the extended filtering user-space program via a circular buffer, where the extended filtering user-space program receives the data. The extended filtering user-space program then filters the received file cache data and sorts and outputs the filtered file cache data.

7. A computer program product, characterized in that, The computer program product includes instructions that, when executed, cause the method as described in any one of claims 1-5 to be implemented.

Images