UFS-oriented high-speed direct data path performance test method and system
By bypassing the Linux block device layer in UFS performance testing, establishing a direct data path, and combining memory mapping and page locking techniques, the problems of lengthy paths and resource contention in traditional testing schemes are solved, enabling efficient and accurate performance testing of high-speed UFS devices.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- LUANQI TECH (SUZHOU) CO LTD
- Filing Date
- 2025-12-16
- Publication Date
- 2026-05-01
AI Technical Summary
Traditional UFS performance testing methods cannot meet the performance requirements of high-speed UFS devices. They suffer from problems such as long data transmission paths, high CPU overhead, insufficient multi-task concurrent processing capabilities, and low memory management efficiency, resulting in distorted and unstable test results.
By establishing a direct data path between user space and kernel space, bypassing the Linux block device layer, pre-allocating a data cache pool and binding test threads to specific CPU processor cores, input and output requests are directly dispatched to the multi-command queue hardware queue of the UFS device driver. Combined with memory mapping and page locking techniques, zero-copy data transfer is achieved.
It significantly improves sequential and random read/write performance, accurately assesses the performance gains brought by the multi-command queue feature, and ensures efficient and stable testing process, as well as accurate and reliable test results.
Smart Images
Figure CN121963830A_ABST
Abstract
Description
A performance testing method and system for high-speed direct data paths in UFS Technical Field
[0001] This invention relates to the field of data storage technology, specifically a high-speed direct data path performance testing method and system for UFS. Background Technology
[0002] Universal Flash Storage (UFS), as a high-performance storage interface, has become a core standard in mobile devices and high-speed storage. With the evolution of the UFS standard to version 4.0 and higher, its single-channel data transfer rate has reached 23.2 Gbps, and key features such as Multiple Command Queues (MCQ) have been introduced, significantly improving the parallel processing capabilities of devices. Read and write performance testing is the core means of verifying and measuring the performance of UFS devices. How to maximize the testing of various UFS performance indicators in multiple scenarios has become the main goal of designing performance testing tools.
[0003] However, traditional UFS performance testing schemes based on the Linux operating system rely on the kernel's block device layer for data transfer. This path begins with an I / O request from user space and involves a complex software stack including the file system, the block device general layer, and the I / O scheduler before finally reaching the UFS driver. This process has several inherent drawbacks and is no longer suitable for the performance requirements of high-speed UFS devices: 1. The data transfer path is lengthy and has high overhead: The traditional path involves multiple data copies between user space and kernel space, as well as complex request establishment and scheduling processes. These operations introduce significant CPU overhead and latency in high-speed data transfer scenarios, becoming new performance bottlenecks and distorting test results, failing to accurately reflect the actual performance of the UFS device.
[0004] 2. Inability to effectively support MCQ feature evaluation: MCQ features aim to achieve parallel processing of commands through multiple independent hardware queues. However, traditional solutions lack multi-task concurrent processing capabilities, and in multi-core CPU environments, resource contention and lock contention issues easily arise in software queues, making it impossible to efficiently and evenly distribute I / O requests to multiple hardware queues. Therefore, it is difficult to comprehensively and accurately evaluate the performance improvement brought by MCQ.
[0005] 3. Inefficient system memory management: Traditional testing tools frequently create and destroy data buffers and do not effectively manage memory pages, which may cause data to be swapped out to external storage during the test, causing performance fluctuations and affecting the stability and reliability of test results. Summary of the Invention
[0006] The purpose of this invention is to provide a high-speed direct data path performance testing method and system for UFS, so as to solve the problems mentioned in the background art.
[0007] To achieve the above objectives, the present invention provides the following technical solution: a high-speed direct data path performance testing method for UFS, comprising a user space processing flow and a kernel space processing flow; wherein, in the user space processing flow, a data cache pool is pre-allocated according to test parameters, and a test thread bound to a specific CPU processor core is created, the test thread reuses the data cache pool to construct input and output requests and issues them through input and output control interfaces; in the kernel space processing flow, input and output requests are received through a dedicated character device node created for the UFS device, and the input and output requests are directly dispatched to the corresponding multi-command queue hardware queue in the UFS device driver for execution using a pre-established mapping and page locking of the user space data cache pool, thereby bypassing the Linux block device layer.
[0008] As a further aspect of the present invention, the specific steps of the user space processing flow are as follows: S11, Data cache pool and execution thread creation: Start the test program, parse the test parameters input by the user, pre-allocate and create a global data cache pool according to the test parameters; then create multiple test threads corresponding to the number of threads, and bind each test thread to a specified CPU processor core; S12, Input and output request construction: Each test thread takes a free data cache block from its allocated data cache pool segment, fills it with test data, and constructs input and output requests; S13, Input and output... Request Issuance: Input and output requests are directly issued to the kernel space through custom input and output control interfaces; S14, Request Result Collection and Analysis: Receive and analyze the request results returned by the kernel space, and decide whether to continue issuing requests or terminate the test based on the test termination condition; S15, Loop Control and Resource Collection: Determine whether there are errors in the request processing results or whether the test termination condition is met; if not, execute steps S12 to S14 in a loop; if yes, terminate the test thread and release the data cache pool; after the test is completed, collect all test threads and release the data cache pool; output a performance report and terminate the operation.
[0009] As a further aspect of the present invention: In step S11, the specific implementation method of test thread creation and CPU processor core binding is as follows: S111, Thread creation and initialization: The test program calls the thread creation interface provided by the operating system according to the test parameters configured by the user to generate a corresponding number of test threads; S112, CPU processor core binding: A one-to-one mapping relationship is established between the test threads and the CPU processor cores; Based on the one-to-one mapping relationship, the execution environment of each test thread is fixed on the CPU processor core it is mapped to through system calls.
[0010] As a further aspect of the present invention: in step S12, the input and output request includes: operation type, data cache address, data length, and target address; wherein, the operation type includes write operation and read operation.
[0011] As a further aspect of the present invention, the specific steps of the kernel space processing flow are as follows: S21, Character device node creation: A dedicated character device node is created for the UFS device under test using the Linux character device driver framework for data flow in performance testing; S22, Data cache pool mapping and page table locking: A permanent memory mapping is established for the user space data cache pool, and the mapped physical memory pages are locked using page table locking to prevent them from being swapped out; S23, Input and output request reception: Input and output requests from user space are received through the character device node; S24, Request and queue binding: Requests are bound to queues according to input and output requests and threads. The CPU processor core binding relationship assigns input and output requests to the corresponding multi-command queue hardware queue in the UFS device driver; S25, UFS device driver result reception: After the UFS device driver completes the input and output request operation, the returned request result is received; and the request result is pushed back to user space; S26, Loop control and resource release: The UFS device driver continues to process requests and determines whether a test end instruction has been received from user space; if not, steps S23 to S25 are executed in a loop; if yes, the memory mapping of the user space data cache pool is released; and after receiving the test end instruction, the memory mapping is released and the relevant resources are released.
[0012] As a further aspect of the present invention: In step S22, the specific method for implementing data cache pool mapping and page table locking is as follows: S221, Data cache pool pre-allocation: During the test initialization phase, a data cache pool is pre-allocated in user space according to the test parameters configured by the user; S222, Data cache pool mapping: In kernel space, the physical page frame of the user space data cache pool is obtained through memory management functions; a direct mapping from kernel address space to physical page frame is established, enabling the underlying UFS device driver to directly access this memory segment; S223, Data cache pool locking: The physical memory page corresponding to the data cache pool is locked by locking the page table to prevent it from being swapped out to external storage devices by the operating system during the test.
[0013] As a further aspect of the present invention: in step S24, the specific method for implementing request binding with queue is as follows: S241, Source information acquisition: acquire input and output requests and their source information; S242, Queue binding: determine a target hardware queue from multiple multi-command queue hardware queues of the UFS device driver according to the source information and a predefined mapping strategy; S243, Hardware queue processing: assign the input and output requests to the target hardware queue for processing.
[0014] A high-speed direct data path performance testing system for UFS comprises a user-space test engine module and a kernel-space driver module. The user-space test engine module includes: a parameter parsing unit for configuring test parameters; a resource pre-allocation unit for pre-allocating a data cache pool; a thread management and binding unit for creating test threads and binding them to specific CPU processor cores; a request construction and distribution unit for constructing input and output requests and distributing them through input and output control interfaces; and a result analysis unit for collecting and analyzing test results. The kernel-space driver module includes: a dedicated character device node serving as a direct connection between user space and the UFS device driver, bypassing the Linux block device layer; a memory mapping and locking unit for mapping user-space data caches and locking memory pages to achieve zero-copy data transfer; a request scheduling unit for directly dispatching received input and output requests to the corresponding UFS device driver's multi-command queue hardware queue based on the CPU processor core binding relationship; and a result feedback unit for returning the execution results of the UFS device driver to user space.
[0015] Compared with existing technologies, the beneficial effects of this invention are as follows: By bypassing the Linux block device layer and establishing a direct data path from user space to the UFS driver, this invention greatly shortens the input and output paths, significantly improves sequential and random read / write performance, and can meet the testing requirements of high-speed UFS devices; by establishing a static mapping relationship between threads, CPU processor cores, and multi-command queue hardware queues, it effectively reduces multi-core resource contention, fully releases the parallel processing capabilities of UFS devices, and accurately evaluates the performance improvement brought by the multi-command queue feature; by adopting unified memory mapping and page locking technology, it achieves zero-copy data transmission and avoids performance jitter from memory paging, ensuring efficient and stable testing; by creating independent UFS character device nodes, it isolates the performance test data stream from regular device access, avoids mutual interference, and ensures the accuracy and reliability of test results. Attached Figure Description
[0016] Figure 1 is a flowchart of user space processing in a high-speed direct data path performance testing method for UFS; Figure 2 is a flowchart of kernel space processing in a high-speed direct data path performance testing method for UFS; Figure 3 is a structural diagram of a high-speed direct data path performance testing system for UFS. Detailed Implementation
[0017] Please refer to Figures 1 and 2. In this embodiment of the invention, a high-speed direct data path performance testing method for UFS includes a user space processing flow and a kernel space processing flow. In the user space processing flow, a data cache pool is pre-allocated according to test parameters, and a test thread bound to a specific CPU processor core is created. The test thread reuses the data cache pool to construct input / output (I / O) requests and issues them through the input / output control (I / OControl, IOCTL) interface. In the kernel space processing flow, input and output are received through a dedicated character device node created for the UFS device. The system requests and utilizes a pre-established mapping of the user-space data cache pool and page locking to directly dispatch input / output (I / O) requests to the corresponding Multiple Command Queues (MCQ) hardware queue in the UFS device driver for execution, thereby bypassing the Linux block device layer.
[0018] Preferably, the specific steps of the user space processing flow are as follows: the request is directly dispatched to the corresponding multi-command queue (MCQ) hardware queue in the UFS device driver for execution, thereby bypassing the Linux block device layer.
[0019] Preferably, the specific steps of the user space processing flow are as follows: S11, Data cache pool and execution thread creation: Start the test program, parse the test parameters input by the user, including the number of threads, queue depth, and requested data size; according to the test parameters, pre-allocate and create a global data cache pool; wherein, the size of the data cache pool... in, For the number of threads, For queue depth, The requested data size; for example, Then allocation is required. A data cache pool is used to avoid the huge overhead of dynamically allocating and releasing memory for each I / O request during testing. Multiple test threads are then created corresponding to the number of threads, and each test thread is bound to a specified CPU processor core; for example, thread 0 is bound to CPU0, thread 1 to CPU1, and so on. The specific implementation methods for test thread creation and CPU processor core binding are as follows: S111, Thread Creation and Initialization: The test program calls the thread creation interface provided by the operating system according to the test parameters configured by the user to generate the corresponding number of test threads; for example, in Linux-based systems, the POSIX thread (pthread) library is typically used. The `pthread_create` function is used to create threads. Each thread, upon creation, is assigned a unique thread identifier (TID) and an entry function. This entry function contains the logic for constructing, sending, and recycling I / O requests that the thread will subsequently execute. S112, CPU processor core binding: Establishing a one-to-one mapping between test threads and CPU processor cores. Based on this mapping, system calls are used to fix the execution environment of each test thread on its mapped CPU processor core. For example, the program first initializes a variable of type `cpu_set_t` using the `CPU_ZERO` macro, which represents a CPU mask. Then, through... The macro sets a specific CPU logical number (e.g., 0, 1, 2, 3...) into the CPU mask mentioned above; for a single thread, typically only one CPU core is set to achieve a one-to-one exclusive binding. Finally, the macro is called... The function takes a thread identifier and a pre-set CPU mask as parameters. When the operating system kernel receives this call, it will force the scheduling of the thread to be restricted to the specified CPU core. This means that the thread can only be scheduled and executed on the specified core and will not run on other CPU cores.
[0020] S12. Input and Output Request Construction: Each test thread retrieves a free data buffer block from its allocated data buffer pool segment, fills it with test data, and constructs input and output (I / O) requests; among which, the construction of input and output... The request includes: operation type, data cache address, data length, and target address (LBA); where, operation... For write operations: the memory block pointed to by the data cache address contains the valid data to be written to the UFS device; before constructing the request, the thread fills this memory block with a preset test data pattern.
[0021] For read operations: the data cache address points to an empty or unverified memory block; after the UFS device completes the read operation, the driver fills this memory block with the data read from the device, which the user-space program can then verify; the data length is in bytes; and the driver generates a SCSI command description block corresponding to this data length based on this value; the target address is used to tell the UFS device where to start reading or writing data; S13, Input and Output Request Issuance: Input and output requests are sent through a custom I / O Control (IOCTL) interface. The request is sent directly to the kernel space; S14, Request Result Collection and Analysis: Receive and analyze the request result returned by the kernel space, and decide whether to continue sending requests or terminate the test based on the test termination condition; S15, Loop Control and Resource Collection: Determine whether there is an error in the request processing result or whether the test termination condition is met; if not, execute steps S12 to S14 in a loop; if yes, terminate the test thread and release the data cache pool; after the test is completed, collect all test threads and release the data cache pool; output a performance report (including average bandwidth, IOPS, latency, etc.) and terminate the operation.
[0022] Preferably, the specific steps of the kernel space processing flow are as follows: S21, Character device node creation: Using the Linux character device driver framework, a dedicated character device node is created for the UFS device under test (e.g., ... For performance testing, the data stream is completely isolated from standard UFS block devices (such as / dev / sdX) to ensure isolation between test traffic and control traffic. S22, Data Cache Pool Mapping and Page Table Locking: A permanent memory mapping to the user-space data cache pool is established, and the mapped physical memory pages are locked using page table locking to prevent them from being swapped out. The specific implementation method is as follows: S221, Data Cache Pool Pre-allocation: During the test initialization phase, a data cache pool is pre-allocated in user space according to the user-configured test parameters. S222, Data Cache Pool Mapping: In kernel space, the physical page frames of the user-space data cache pool are obtained through memory management functions; a direct mapping from the kernel address space to the physical page frames is established, allowing the underlying UFS device driver to directly access this memory segment; for example, obtaining the physical page frame: the driver calls... Function; this function will trace back The corresponding physical page frames are obtained, and these pages are pinned (by increasing their reference count) to prevent them from being freed or used for other purposes; they are mapped to the kernel address space: after obtaining the physical page frames, the driver... or The function maps these physical page frames into the kernel's address space, thereby generating a kernel virtual address. The device driver will eventually The corresponding physical address information is directly set into the scattering and aggregation list of the UFS command request; S223, Data Cache Pool Locking: The physical memory pages corresponding to the data cache pool are locked using a page table locking method to prevent them from being swapped out to external storage devices by the operating system during testing; the page table locking method is achieved by calling... or System call implementation; for example, by calling The system call locks the data pool in physical memory; the call forces the virtual address to be locked. Start, length is All physical pages corresponding to the memory region reside in physical memory. In, until it is unlocked; S23, Input and output request reception: Receive input and output from user space through the character device node. The request, i.e., the one in step S13 S24. Request and queue binding: based on input and output. The binding relationship between requests and threads and CPU processor cores, including input and output. The request is assigned to the corresponding Multiple Command Queuing (MCQ) hardware queue in the UFS device driver; the specific implementation method is as follows: S241, Source Information Acquisition: Acquire input and output. Request and its source information; where the source information is generated The identifier of the CPI processor core to which the requested thread is bound; S242, Queue Binding: Based on the source information and a predefined mapping strategy, determine a target hardware queue from multiple multi-command queue (MCQ) hardware queues of the UFS device driver; wherein, the predefined mapping strategy is a static binding relationship between the CPU processor core and the multi-command queue (MCQ) hardware queue; the static binding relationship is a one-to-one mapping, that is: binding the input and output generated by the thread on CPU processor core i. The request is assigned to a multi-command queue hardware queue i; where i is an integer starting from 0; S243, Hardware queue processing: input and output... The request is assigned to the target hardware queue for processing, bypassing the Linux operating system's block device layer. Assuming the system has four MCQ hardware queues (Q0, Q1, Q2, Q3) configured to correspond one-to-one with CPUs 0-3, requests from threads bound to CPU1 will be directly dispatched to hardware queue Q1. This core-queue binding method significantly reduces lock contention when multiple CPU cores access the same hardware queue simultaneously, improving parallel efficiency. S25, UFS device driver result reception: Waiting for the UFS device driver to complete input and output. After the request operation, the returned request result is received; and the request result is pushed back to the user space; that is, the user space thread waiting for the result in step S14 is awakened; S26, loop control and resource release: the UFS device driver continues to process the request and determines whether a test end instruction has been received from the user space; if not, steps S23 to S25 are executed in a loop; if so, the memory mapping of the user space data cache pool is released; and after receiving the test end instruction, the memory mapping is released and the relevant resources are released.
[0023] Suppose we want to test the performance of a UFS 4.0 device in 4-thread, queue depth 128, and 4KB random write mode; the traditional approach is as follows: the test program calls the write system call; data is copied from the user buffer to the kernel page cache (one copy); it passes through the VFS layer, block device layer, and I / O scheduler (e.g., ... The complex processing involves multiple context switches and data copies, which may require merging and sorting operations. Finally, the SCSI upper-layer driver converts the Bio into SCSI commands, sends them to the UFS device driver, and places them in its (potentially non-MCQ) request queue. As can be seen, the entire path is lengthy, involving multiple context switches and data copies, and cannot fully utilize hardware performance.
[0024] The solution of this invention is as follows: User space processing: A 2MB data pool is pre-allocated in user space, and four threads are created and bound to CPU0-3 respectively; Thread 0 constructs a 4KB write request and sends it directly to / dev / ufs_perf_test via IOCTL; Kernel space processing: The driver has mapped and locked the 2MB of user space memory; upon receiving the request, based on thread 0 being bound to CPU0, the request is directly dispatched to the UFS hardware queue Q0; the UFS hardware processes the requests in Q0-Q3 in parallel; it can be seen that: the solution of this invention skips the entire block device layer, and the path is: user thread → IOCTL → UFS device driver → MCQ hardware; the kernel directly submits the SCSI WRITE command to the memory mapped in user space, without copying data; and: CPU0's requests are always sent to Q0, and CPU1's requests are sent to Q1, fundamentally avoiding the problem of multiple cores contending for the same queue lock.
[0025] In summary, compared with traditional solutions, this invention can maximize the 23.2Gbps high bandwidth and MCQ low latency concurrency capabilities of UFS hardware. The measured speed and IOPS (I / O operations per second) are closer to the theoretical limit of the hardware, and random read and write performance can be significantly improved (e.g., more than 80% compared with traditional solutions), thus truly and accurately reflecting the actual performance of UFS devices.
[0026] Referring to Figure 3, in this embodiment of the invention, a high-speed direct data path performance testing system for UFS consists of a user-space test engine module and a kernel-space driver module. The user-space test engine module includes: a parameter parsing unit for configuring test parameters; a resource pre-allocation unit for pre-allocating a data cache pool; a thread management and binding unit for creating test threads and binding them to specific CPU processor cores; and a request construction and distribution unit for constructing inputs and outputs. Request and control via input and output The interface is distributed; the result analysis unit is used to collect and analyze test results; the kernel space driver module includes: a dedicated character device node, serving as a direct connection channel between user space and the UFS device driver to bypass the Linux block device layer; a memory mapping and locking unit, used to map user space data caches and lock memory pages to achieve zero-copy data transfer; and a request scheduling unit, used to schedule received inputs and outputs. Requests are directly assigned to the multi-command queue of the corresponding UFS device driver based on CPU processor core binding relationships. Hardware queue; Result feedback unit, used to return the execution results of the UFS device driver to user space.
[0027] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.
Claims
1. A performance testing method for high-speed direct data paths in UFS, characterized in that, This includes user space processing and kernel space processing. In the user space processing, a data cache pool is pre-allocated according to test parameters, and test threads bound to specific CPU processor cores are created. The test threads reuse the data cache pool to construct input and output requests and issue them through input and output control interfaces. In the kernel space processing, input and output requests are received through a dedicated character device node created for the UFS device. Using a pre-established mapping to the user space data cache pool and page locking, the input and output requests are directly dispatched to the corresponding multi-command queue hardware queue in the UFS device driver for execution, thus bypassing the Linux block device layer.
2. The method for testing the performance of a high-speed direct data path for UFS according to claim 1, characterized in that, The specific steps of the user space processing flow are as follows: S11, Data cache pool and execution thread creation: Start the test program, parse the test parameters input by the user, and pre-allocate and create a global data cache pool according to the test parameters; Multiple test threads corresponding to the number of threads are created, and each test thread is bound to a specified CPU processor core; S12, Input and output request construction: Each test thread takes a free data cache block from its allocated data cache pool segment, fills it with test data, and constructs input and output requests; S13, Input and output request delivery: Input and output requests are directly delivered to the kernel space through a custom input and output control interface; S14, Request result recycling and analysis: The request results returned by the kernel space are received and analyzed, and the test termination condition is used to decide whether to continue sending requests or terminate the test; S15, Loop control and resource recycling: It is determined whether there are errors in the request processing results or whether the test termination condition is met; if not, steps S12 to S14 are executed repeatedly; if yes, the test thread is terminated and the data cache pool is released; after the test is completed, all test threads are recycled and the data cache pool is released; a performance report is output and the operation ends.
3. The method for testing the performance of a high-speed direct data path for UFS according to claim 2, characterized in that, In step S11, the specific implementation method of test thread creation and CPU processor core binding is as follows: S111, Thread creation and initialization: The test program calls the thread creation interface provided by the operating system according to the test parameters configured by the user to generate a corresponding number of test threads; S112, CPU processor core binding: Establish a one-to-one mapping relationship between test threads and CPU processor cores; According to the one-to-one mapping relationship, the execution environment of each test thread is fixed on the CPU processor core it is mapped to through system calls.
4. The method for testing the performance of a high-speed direct data path for UFS according to claim 2, characterized in that, In step S12, the input and output requests include: operation type, data cache address, data length, and target address; wherein, the operation type includes write operation and read operation.
5. The method for testing the performance of a high-speed direct data path for UFS according to claim 1, characterized in that, The specific steps of the kernel space processing flow are as follows: S21, Character device node creation: Through the Linux character device driver framework, a dedicated character device node is created for the UFS device under test for use in the data stream of performance testing; S22. Data Cache Pool Mapping and Page Table Locking: Establish a permanent memory mapping to the user space data cache pool and lock the mapped physical memory pages using page table locking to prevent them from being swapped out. S23. Input and Output Request Reception: Receive input and output requests from user space via character device nodes. S24. Request and Queue Binding: Assign input and output requests to the corresponding multi-command queue hardware queue in the UFS device driver based on the binding relationship between the input and output requests and the threads and CPU processor cores. S25. UFS Device Driver Result Reception: After the UFS device driver completes the input and output request operations, receive the returned request results and push the results back to user space. S26. Loop Control and Resource Release: The UFS device driver continuously processes requests and determines whether a test end command has been received from user space. If not, steps S23 to S25 are executed repeatedly. If yes, the memory mapping to the user space data cache pool is released, and upon receiving the test end command, the memory mapping is released and related resources are released.
6. The method for testing the performance of a high-speed direct data path for UFS according to claim 5, characterized in that, In step S22, the specific methods for implementing data cache pool mapping and page table locking are as follows: S221, Data cache pool pre-allocation: During the test initialization phase, a data cache pool is pre-allocated in user space according to the test parameters configured by the user; S222, Data cache pool mapping: In kernel space, the physical page frame of the user space data cache pool is obtained through memory management functions; a direct mapping from kernel address space to physical page frame is established, enabling the underlying UFS device driver to directly access this memory segment; S223, Data cache pool locking: The physical memory page corresponding to the data cache pool is locked by locking the page table to prevent it from being swapped out to external storage devices by the operating system during the test.
7. A method for testing the performance of a high-speed direct data path for UFS according to claim 5, characterized in that, In step S24, the specific method for implementing request binding to queue is as follows: S241, Source information acquisition: Acquire input and output requests and their source information; S242, Queue binding: Determine a target hardware queue from multiple multi-command queue hardware queues of the UFS device driver according to the source information and a predefined mapping strategy; S243, Hardware queue processing: Assign the input and output requests to the target hardware queue for processing.
8. A system for implementing the high-speed direct data path performance testing method for UFS as described in any one of claims 1-7, characterized in that, It consists of a user-space test engine module and a kernel-space driver module. The user-space test engine module includes: a parameter parsing unit for configuring test parameters; a resource pre-allocation unit for pre-allocating a data cache pool; a thread management and binding unit for creating test threads and binding them to specific CPU processor cores; a request construction and distribution unit for constructing input and output requests and distributing them through input and output control interfaces; and a result analysis unit for collecting and analyzing test results. The kernel-space driver module includes: a dedicated character device node, serving as a direct connection between user space and the UFS device driver to bypass the Linux block device layer; a memory mapping and locking unit for mapping user-space data caches and locking memory pages to achieve zero-copy data transfer; a request scheduling unit for directly dispatching received input and output requests to the corresponding UFS device driver's multi-command queue hardware queue based on the CPU processor core binding relationship; and a result feedback unit for returning the execution results of the UFS device driver to user space.