A memory test method, device, apparatus and medium

Abstract

The application discloses a memory testing method, device, equipment and medium in the computer technical field. The application can reduce the test interference caused by the operating system scheduling and the background process, bind the test process and the processor core, set exclusive mapping for the physical memory partition, limit the operation of the operating system on the memory, reduce the influence of the operating system on the memory test, make the test running state more stable, and improve the reproducibility of the test data. In the application, the processor architecture is identified first, and the corresponding driver is loaded, so that the hardware equipment of various different architectures can be adapted, and various operating system environments can be compatible. Different test algorithms can be allocated to independent memory partitions and executed in parallel, corresponding test algorithms can be used according to different hardware verification requirements, and the diversified hardware test scene can be adapted.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a memory testing method, apparatus, device, and medium. Background Technology

[0002] Currently, memory stress testing is often performed at the operating system user level. During program execution, it is subject to continuous interference from system scheduling mechanisms, background concurrent processes, etc., making it difficult to maintain stable test running status and read / write timings, and limiting the reproducibility of test results. At the same time, the underlying adaptation logic of conventional testing tools is relatively fixed, only adapting to a single processor architecture and a specific operating system environment, and it is difficult to cover diverse hardware testing scenarios. Summary of the Invention

[0003] In view of this, the purpose of this application is to provide a memory testing method, apparatus, device and medium to reduce the impact of the operating system on memory testing and to adapt to a variety of hardware devices with different architectures and diverse hardware testing scenarios.

[0004] Firstly, this application provides a memory testing method, including: In response to a test request, identify the device processor's architecture type and load the corresponding driver; Establish the binding relationship between each test process in user space and each core of the device processor, as well as the exclusive mapping relationship between each test process and each memory partition in the physical memory area of ​​the device processor, and prohibit the operating system layer from operating on the physical memory area. Based on the binding relationship and exclusive mapping relationship, control each test process to run different test algorithms in parallel to test the corresponding memory partition.

[0005] Optionally, identify the device processor's architecture type and load the corresponding driver, including: The target instruction is invoked to collect the number of processor cores, number of memory channels, total physical memory, memory controller model, error check enable status, and communication status of the device, thereby obtaining a hardware information table; Identify the architecture type according to the hardware information table; The system queries the preset driver library for the driver corresponding to the architecture type and loads the found driver.

[0006] Optionally, establish a binding relationship between each test process in user space and each core of the device processor, including: The objective function is used to establish the binding relationship between each test process and each core.

[0007] Optionally, the exclusive mapping relationship between each test process and each memory partition in the physical memory area of ​​the device processor includes: Divide the physical memory area into various memory partitions; The physical address and direct access permissions of each memory partition are forcibly bound to the corresponding test process to establish an exclusive mapping relationship.

[0008] Optionally, the operating system layer can be prevented from operating on physical memory areas, including: Each memory partition is marked as locked, so that the operating system layer prohibits the reclamation operation of the corresponding user memory area based on the locked status.

[0009] Optionally, it also includes: Monitor the load information of each test process; If the load information of any test process exceeds the limit, the memory partition corresponding to that test process will be split and allocated to other test processes whose load information does not exceed the limit.

[0010] Optionally, it also includes: Error verification data is injected during the testing process, and memory fault information is collected. If an unrecoverable failure is confirmed in any memory partition through analysis of memory fault information, testing of that memory partition is paused, while the testing process for other memory partitions continues.

[0011] Secondly, this application provides a memory testing apparatus, comprising: The loading module is used to respond to test requests, identify the architecture type of the device processor, and load the corresponding driver; The mapping module is used to establish the binding relationship between each test process in user space and each core of the device processor, as well as the exclusive mapping relationship between each test process and each memory partition in the physical memory area of ​​the device processor, and to prohibit the operating system layer from operating on the physical memory area. The testing module is used to control various test processes to run different test algorithms in parallel to test the corresponding memory partitions according to the binding relationship and exclusive mapping relationship.

[0012] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor for executing the computer program to implement the aforementioned disclosed memory testing method.

[0013] Fourthly, this application provides a non-volatile storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the aforementioned disclosed memory testing method.

[0014] Fifthly, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the aforementioned disclosed memory testing method.

[0015] As can be seen, this application can reduce test interference caused by operating system scheduling and background processes. By binding the test process to the processor core and setting exclusive mapping for physical memory partitions and restricting the operating system's operations on memory, the impact of the operating system on memory testing is reduced, making the test run more stable and improving the reproducibility of test data. Specifically, this application first identifies the processor architecture and loads the corresponding driver, enabling it to adapt to various hardware devices with different architectures and be compatible with multiple operating system environments. Different test algorithms can be allocated to independent memory partitions for parallel execution, allowing the use of corresponding test algorithms according to different hardware verification requirements, which is beneficial for adapting to diverse hardware testing scenarios.

[0016] Correspondingly, the memory testing device, equipment, medium, and program product provided in this application also have the above-mentioned technical effects. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0018] Figure 1 This is a flowchart of a memory testing method disclosed in this application; Figure 2 This is a schematic diagram of a memory stress testing system disclosed in this application; Figure 3 This is a flowchart of another memory testing method disclosed in this application; Figure 4 This is a schematic diagram of a memory testing device disclosed in this application; Figure 5 This is a schematic diagram of an electronic device disclosed in this application; Figure 6 A server architecture diagram provided for this application; Figure 7 A terminal structure diagram provided for this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0020] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0021] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0022] Currently, memory stress testing is often performed at the operating system user level. During program execution, it is subject to continuous interference from system scheduling mechanisms and background concurrent processes, making it difficult to maintain stable test running status and read / write timings, and limiting the reproducibility of test results. Furthermore, the underlying adaptation logic of conventional testing tools is relatively fixed, only adapting to a single processor architecture and specific operating system environment, and failing to cover diverse hardware testing scenarios. Therefore, this application provides a memory testing solution that reduces the impact of the operating system on memory testing and adapts to various hardware devices with different architectures and diverse hardware testing scenarios.

[0023] See Figure 1 As shown in the figure, this application discloses a memory testing method, including: S101. In response to the test request, identify the architecture type of the device processor and load the corresponding driver.

[0024] This embodiment can invoke target instructions to collect the number of processor cores, number of memory channels, total physical memory capacity, memory controller model, ECC (Error-Correcting Code) enable status, and hardware communication status (e.g., communication status with the BMC) of the device. A hardware information table is generated from the collected parameters. Then, based on this hardware information table, the processor architecture type is identified. Finally, a driver matching the current architecture type is retrieved from a pre-stored driver library and loaded. The target instructions are adapted to different processor architectures, such as MOVNT for x86 platforms and DCZVA for ARM platforms. Therefore, in one implementation, identifying the device processor architecture type and loading the corresponding driver includes: invoking target instructions to collect the number of processor cores, number of memory channels, total physical memory, memory controller model, error-correcting code enable status, and communication status of the device processor to obtain a hardware information table; identifying the architecture type according to the hardware information table; querying the driver corresponding to the architecture type in the preset driver library; and loading the queried driver.

[0025] S102. Establish the binding relationship between each test process in user space and each core of the device processor, as well as the exclusive mapping relationship between each test process and each memory partition in the physical memory area of ​​the device processor, and prohibit the operating system layer from operating on the physical memory area.

[0026] In one implementation, establishing a binding relationship between each test process in user space and each core of the device processor includes: using an objective function (such as the scheduling affinity function sched_setaffinity) to establish a binding relationship between each test process and each core, so as to limit a single process to run only on a specified processor core.

[0027] Regarding the exclusive mapping relationship between processes and memory partitions, this embodiment first divides the entire physical memory region into several independent memory partitions. Then, it forcibly associates the physical address and direct access permissions corresponding to each memory partition with a single test process, thereby forming an exclusive mapping relationship that does not interfere with each other. Specifically, a combination of mmap (memorymap), DAX (Direct Access), and MAP_FIXED (fixed address mapping) methods can be used to complete the construction of the exclusive mapping relationship. Therefore, in one implementation, the exclusive mapping relationship between each test process and each memory partition in the physical memory region of the device processor includes: dividing the physical memory region into various memory partitions; and forcibly binding the physical address and direct access permissions of each memory partition with the corresponding test process to establish the corresponding exclusive mapping relationship.

[0028] In one implementation, prohibiting the operating system layer from operating on physical memory areas includes: marking the user memory area corresponding to each memory partition as locked, so that the operating system layer can confirm that the virtual user memory area in the corresponding user space is locked based on the locked status, thereby prohibiting the reclamation operation of each memory partition. Here, user space is a logical virtual memory area, which is divided into various user memory areas according to the division of each memory partition. In one example, it can be considered that a test process manages a user memory area, and this user memory area is mapped to a certain physical memory partition. At any given time, the corresponding test process performs exclusive read, write, and delete operations on the corresponding physical memory partition through the corresponding user memory area.

[0029] S103. Based on the binding relationship and exclusive mapping relationship, control each test process to run different test algorithms in parallel to test the corresponding memory partition.

[0030] It should be noted that the correspondence between test algorithms and memory partitions supports multiple allocation modes. The first mode matches different partitions with different algorithms, such as using Gray code and enhanced March to test different memory partitions, ensuring that inter-partition testing does not interfere with each other. The second mode configures multiple partitions with the same algorithm, facilitating batch comparison of operational metrics across different partitions using the same algorithm. The third mode runs multiple complementary algorithms on the same partition, executing multiple types of test logic sequentially within a single physical memory area, allowing for easy comparison of test information for different algorithms within the same physical memory area. These allocation methods can be switched as needed to adapt to different hardware verification requirements. Furthermore, the testing process continuously collects ECC (Error-Correcting Code) and access latency information; in the event of an unrecoverable failure, only the corresponding partition's task is paused, while the remaining partitions continue running. Therefore, in one implementation, the method also includes: monitoring the load information of each test process; if the load information of any test process exceeds the limit, the memory partition corresponding to that test process is split and allocated to other test processes whose load information does not exceed the limit.

[0031] This embodiment can also proactively inject ECC (Error-Correcting Code) type verification data into the testing process and simultaneously collect various memory fault-related information. The collected fault information is analyzed, and if an unrecoverable fault is determined in a certain memory partition, the testing operation for that partition is stopped, while the testing process for other memory partitions continues to run normally. Therefore, in one implementation, it further includes: injecting error verification data during the testing process and collecting memory fault information; if an unrecoverable fault is confirmed in any memory partition through analysis of the memory fault information, the testing of that memory partition is paused, while the testing process for other memory partitions is maintained.

[0032] Furthermore, to obtain comprehensive test results data, relevant hardware and software data can be captured synchronously at fixed intervals. At the performance level, data on access latency, throughput, and process load for each memory partition are collected. At the hardware fault level, ECC (Error-Correcting Code) errors, bit flips, address anomalies, and other fault information are fully recorded. The fault occurrence time, corresponding memory partition, running algorithm, and hardware temperature and power consumption parameters are also retained synchronously. When a fault is triggered, the original memory data surrounding the fault address is additionally saved. Controllable verification faults are actively injected during the test, allowing for the synchronous collection of corresponding feedback data to verify the effectiveness of the detection mechanism. After the test, all collected data is uniformly summarized for result analysis. Performance differences under different partition and algorithm allocation modes are differentiated, the frequency and distribution of various faults are statistically analyzed, and the fault detection effects are compared under modes such as single partition with multiple algorithms and multiple partitions with different algorithms, in order to locate defective memory hardware areas. These results can then be compiled into a complete statistical record.

[0033] As can be seen, this embodiment can reduce test interference caused by operating system scheduling and background processes. By binding the test process to the processor core, setting exclusive mapping for physical memory partitions, and restricting the operating system's operation on memory, the impact of the operating system on memory testing is reduced, making the test run more stable and improving the reproducibility of test data. Specifically, identifying the processor architecture and loading the corresponding driver first can adapt to various hardware devices with different architectures and be compatible with multiple operating system environments. Different test algorithms can be allocated to independent memory partitions for parallel execution, allowing the use of corresponding test algorithms according to different hardware verification requirements, which is beneficial for adapting to various hardware testing scenarios.

[0034] In another embodiment, a memory stress testing system that bypasses operating system intervention is provided. This system can run independently within the host operating system environment, eliminating operational interference from operating system memory management and process scheduling. The system adopts a three-tiered architecture, relying on a hardware abstraction layer to achieve cross-architecture adaptation and direct access to underlying hardware. It incorporates a configurable parallel testing engine and, based on intelligent task scheduling and real-time hardware monitoring mechanisms, performs stress testing and fault identification on the memory subsystem while maintaining test efficiency. This solution directly manages underlying hardware resources such as the memory controller, CPU cache, and physical memory chips within the operating system runtime environment, fundamentally eliminating test interference caused by operating system memory reclamation, memory swapping, and process scheduling.

[0035] This memory stress testing system is applicable to the following scenarios.

[0036] Server production line rapid quality inspection scenario: This system can be deployed in lightweight operating system environments such as customized Linux, requiring no complex system environment configuration. Based on a low-power parallel testing mode, it can complete a comprehensive test of all memory modules of a single server within 30 minutes, covering hidden hardware faults caused by error check codes. Compared to traditional testing tools, this system can shorten the overall testing time by more than 60%, reduce energy consumption costs, and improve the problems of low testing efficiency and susceptibility to operating system interference of traditional tools.

[0037] Customized verification scenarios for embedded devices: For embedded hardware devices with reduced instruction set architecture, the system generates customized test tasks adapted to different memory specifications such as low-power double data rate memory and fifth-generation double data rate memory based on the adaptive driver loading capability of the hardware abstraction layer. It performs targeted stress testing on the core memory area of ​​the embedded system, solving the problems of weak cross-platform adaptability and fixed and unadjustable test operation mode of existing test tools, and ensuring the reliability of memory operation in embedded scenarios such as automotive and industrial control.

[0038] High-reliability data center operation and maintenance scenarios: The system supports non-intrusive deployment and can perform background health monitoring of online server memory in the data center without interrupting existing server business processes. Through a millisecond-level hardware indicator sampling mechanism and error check code fault tracing capabilities, the system can proactively identify potential hidden memory faults, avoid business interruptions caused by sudden memory failures, and solve the problems of traditional testing tools being unable to perform online testing while the business is running and having weak fault early warning capabilities.

[0039] This test framework adopts an architecture that combines operating system adaptation with direct hardware access. It does not rely on the host operating system's native memory management module and does not call standard operating system memory allocation interfaces such as dynamic memory allocation and deallocation functions. In the operating system's user environment, the system interacts directly with the platform's hardware controller based on low-level assembly instructions and kernel-mode drivers. Its core technical implementation path is based on the operating system's memory mapping system calls, overlaid with fixed address mapping identifiers and direct access mode, directly mapping physical memory addresses to the test process's user space after aligning them according to memory page boundaries. The system disables the operating system's caching and memory address translation mechanisms through architecture configuration instructions, and configures the cache disable bit in control register 0 for x86 architecture, ensuring that test read / write data bypasses the CPU cache and is not interfered with by the operating system's process scheduling and memory swapping mechanisms, directly writing to or reading from physical memory chips. The system can call the operating system kernel-mode interface through the hardware abstraction layer to directly access the internal registers of the memory controller, autonomously configure memory timing parameters such as memory refresh frequency and column address gating delay, as well as underlying hardware attributes such as error check code correction strategies, and actively trigger hardware faults related to timing parameters and error check code mechanisms. This fills the blind spots in the underlying hardware control of existing testing tools, enabling test results to truly reflect the inherent performance and operational stability of memory hardware.

[0040] The system achieves dual decoupling between processor architecture and operating system based on a layered hardware abstraction layer. This hardware abstraction layer comprises three functional units: an architecture identification module, a driver adaptation module, and an operating system adaptation module. The architecture identification module automatically identifies the processor type through multi-architecture instruction set compatibility logic. For x86 architecture, it calls the processor identification instruction to collect hardware parameters; for ARM architecture, it reads the multi-processor identification register; and for RISC-V architecture, it calls the architecture detection interface to obtain hardware information such as processor model, number of cores, number of memory channels, and memory controller specifications. The driver adaptation module has a built-in multi-architecture low-level driver library and dynamically loads matching hardware drivers based on the architecture identification results. The operating system adaptation module is compatible with mainstream operating systems such as Linux, Windows, and lightweight real-time operating systems. By adapting to the kernel interfaces and system calls of different systems, it stably implements direct hardware access and parallel testing functions in various system environments. This framework can adapt to different combinations of operating systems and hardware architectures without modifying the core program code, broadening the system's application coverage.

[0041] The system testing engine incorporates multiple dedicated memory testing algorithms, forming a comprehensive testing system covering basic explicit faults, deep implicit faults, and low-power operating conditions. Among them, the Walking Ones / Zeroes algorithm detects memory bit-flipping hardware faults through single-bit flip traversal. The address line perturbation mode combines random address jumps and continuous address scanning operations to verify the correctness of the memory address decoder. The chessboard mode uses alternating 0x5555 and 0xAAAA data writes to detect memory cell coupling faults. The enhanced Gray code mode and enhanced March algorithm are the core algorithms of this system. Gray code utilizes the inherent characteristic of adjacent data bits flipping only by one bit, combined with 8-bit, 16-bit, and 32-bit multi-precision sequence switching mechanisms, reducing the number of data bus level flips during testing by 40%, adapting to long-term low-power testing conditions on production lines. The enhanced March algorithm adds a loop operation sequence of read 0, write 1, read 1, write 0, and read 0 to the traditional March C+ algorithm. Combined with a bidirectional scanning mechanism of ascending and descending memory addresses, it improves the detection rate of dynamic coupling faults and timing-related faults by more than 35%, and captures deep hidden memory faults.

[0042] This memory testing system adopts a three-tiered architecture consisting of a hardware abstraction layer, a test engine layer, and a control interface layer. Its core innovations revolve around three directions: direct access to physical memory without intermediaries, end-to-end operating system interference shielding, and intelligent matching and scheduling of algorithms and memory partitions. It breaks through the technical bottlenecks of traditional memory testing, which relies on general system calls, is affected by page caching, memory swapping, process scheduling interference, and has coarse granularity in memory partition control. It achieves the technical effects of test load directly reaching memory hardware particles, no system intervention throughout the testing process, and precise and targeted configuration of test scenarios.

[0043] The Hardware Abstraction Layer (HAL) is the core layer for low-level system interaction, located between the test engine layer and physical hardware devices. Its core function is to build a direct hardware access channel that bypasses the operating system's memory management stack, constructing a full-link operating system interference shielding system from three dimensions: address mapping, cache bypass, and process isolation. This layer also undertakes the core functions of hardware parameter acquisition, low-level driver adaptation, precise physical memory mapping, and cache bypass control. Each functional submodule interacts with the hardware devices through an advanced high-performance bus adapter interface.

[0044] The architecture detection module collects basic hardware parameters through a multi-architecture compatible instruction set, identifies core hardware information such as processor architecture model, number of cores, number of memory channels, total physical memory capacity, memory controller model, and error check code enable status, generates a hardware information table and pushes it to the parallel test scheduler in the test engine layer. At the same time, it outputs the current device architecture type to the driver adaptation module, triggering the automatic loading process of the corresponding underlying driver.

[0045] The driver adaptation and memory mapping module is a core unit of the hardware abstraction layer, combining driver adaptation and memory mapping functions to provide underlying support for direct access to physical memory, first-layer operating system interference shielding, and partition-oriented mapping. Based on the identification results output by the architecture detection module, this module loads low-level drivers adapted to x86, ARM, and other architectures from the system's built-in driver library, establishing a controllable interaction channel between the test system and the hardware platform. It employs a three-stage architecture of topology resolution, precise mapping, and strong isolation verification. Based on a combination of memory mapping and direct access mode with fixed address mapping identifiers, it achieves direct, uninterrupted mapping from physical memory to the test process's user space. It supports multi-granularity partition mapping by memory channel and memory logical storage block, with single-partition mapping latency consistently controlled within ten microseconds. Through a page table-level access isolation mechanism, it shields non-test processes from accessing the target memory.

[0046] The driver adaptation and memory mapping module can achieve the following functions.

[0047] First, physical memory topology parsing and partition address pre-calculation. After the underlying driver is loaded, the module directly reads the address decoding configuration register, channel interleaving rules, and memory logical storage block address mask from the memory controller through the driver layer. It then parses the bit offset positions and decoding logic of the channel number and memory logical storage block number in the physical address bits. The system traverses the entire physical address space page by page, aggregating the corresponding physical page frame addresses according to the dimensions of memory channel and memory logical storage block. Unmappable memory ranges such as system reserved intervals and kernel occupied intervals are removed. After two-megabyte large page address alignment processing, a mappable partition address table is generated. This step solves the problem of directional mapping caused by the non-contiguous physical addresses of channels and memory logical storage blocks under memory address interleaving conditions. The partition address matching accuracy reaches 100%, providing address support for subsequent fine-grained directional testing.

[0048] Second, a combined direct access mapping mechanism. Through a three-layer collaborative mechanism, it bypasses the intermediate layers of the operating system's memory management, enabling direct read / write access from user space to physical memory and eliminating interference from the operating system's memory management policies. System calls are used to map memory to physical memory character devices verified by the driver, passing in shared mapping attributes to prevent copy-on-write behavior in private mapping modes. This ensures strong consistency between process virtual addresses and physical memory data read / write, avoiding test address offsets and load distortion caused by the operating system's copy-on-write mechanism. The system overlays fixed address mapping identifiers, completing fixed-location mapping within a pre-allocated contiguous virtual address pool for the test process. This ensures that the mapped virtual addresses are strictly aligned according to cache lines and large page boundaries, providing an address basis for the continuous virtual mapping of discrete physical pages and avoiding memory access timing fluctuations caused by random address allocation in the kernel. The system enables a direct access mechanism by modifying the page table entry attributes corresponding to the mapping interval at the driver layer, clearing page cache association identifiers, and bypassing the operating system's page cache, write-back queue, and memory swapping logic. This allows user space read / write requests to directly penetrate to physical memory particles, eliminating interference from page cache hits and write-back latency on test load and performance metrics. The system adopts a batch page table update mechanism, which completes the page table configuration of all physical pages of the entire partition in a single system call, replacing the traditional single-page sequential mapping method, improving mapping efficiency by more than 80%, and controlling the single partition mapping latency to within ten microseconds.

[0049] Third, multi-granularity partition-oriented mapping. Based on a pre-generated partition address table, the system supports two levels of fine-grained directional mapping: memory channel level and memory logical storage block level, adapting to different granularity testing needs. When mapping by memory channel, the system allocates an independent virtual address segment for each memory channel. Through multiple memory mappings superimposed with fixed address mapping identifier calls, the physical page frames corresponding to different channels are mapped to the corresponding virtual address segments, forming a one-to-one correspondence between virtual address segments and physical memory channels. The test process can access different virtual address segments to directionally hit the target memory channel, realizing scenarios such as single-channel fault location, multi-channel parallel stress testing, and inter-channel crosstalk verification. When mapping memory logical storage blocks, the system uses discrete physical page frame continuous virtual mapping technology to sequentially map non-contiguous physical page frames corresponding to the same memory logical storage block to the same continuous virtual address range through fixed address mapping identifiers. When the test process accesses this virtual range, the read and write requests accurately hit the target physical memory logical storage block without the need for additional address jump calculations. This enables fine-grained verification scenarios such as single memory logical storage block fault injection and inter-block coupling fault testing, and the test positioning accuracy is improved by an order of magnitude compared to the traditional address segment mapping method.

[0050] Fourth, a strong isolation protection mechanism for the mapped region. A two-layer page table control mechanism ensures exclusive access to the test memory, eliminating interference from other user processes and kernel threads. At the user-mode permission level, the system calls the memory permission configuration function to set the mapped memory region to be readable and writable only by the user group belonging to the test process, disabling all access permissions for other users and blocking illegal user-mode access paths. At the kernel page table level, the system modifies the global page table access control flag corresponding to the target physical page through the underlying driver, setting the page table entries corresponding to non-test processes to an inaccessible state, intercepting memory mapping requests from other processes for this physical memory region, ensuring that the target memory is exclusively accessed by the test process during the test period, guaranteeing the accuracy and reproducibility of the test results. After mapping is completed, the system performs a two-step closed-loop verification process—page table readback verification and address matching verification—to confirm the mapping relationship and isolation mechanism are effective before proceeding to the subsequent testing process.

[0051] The cache and hardware control module is a second-layer operating system interference shielding unit. It shields the system's default hardware policies from the two dimensions of CPU cache bypass and memory controller parameter direct matching, ensuring that the test pressure is directly applied to the memory chips. At the same time, it can actively construct extreme hardware operating environments.

[0052] The cache and hardware control module can perform the following functions.

[0053] First, non-temporary storage bypasses cache execution. The module adapts instruction sets for both x86 and ARM architectures, bypassing all levels of the CPU cache throughout the process to eliminate the dilution effect of cache hits on test load intensity and access latency metrics. During the test startup phase, the system automatically identifies the processor architecture and instruction set support capabilities. For x86 architecture, it adapts to the MOVNT series of streaming non-temporary storage instructions; for ARM architecture, it adapts to the DC ZVA cache line clearing instruction paired with STNP non-temporary paired storage instructions. Upper-level test algorithms can run across platforms without modification, ensuring architectural compatibility of the cache bypass logic. The system corrects test address alignment at the processor cache line granularity, and performs non-temporary read / write operations on entire cache lines in the main test interval, avoiding implicit cache write-backs caused by misaligned accesses and ensuring consistent cache bypass performance. The system batch replaces regular write operations in the test algorithm with non-temporary storage instructions, and adds hardware memory barrier instructions for read operations. For x86 architecture, it uses LFENCE / SFENCE barrier instructions, and for ARM architecture, it uses DMB barrier instructions, forcing read / write instructions to be submitted in program order, preventing out-of-order execution of the CPU and write buffer merging from interfering with test timing. After each round of testing, the system reads the last-level cache hit counter from the performance monitoring unit to verify that the cache hit rate in the test interval does not exceed one percent. If it exceeds the threshold, the system automatically adjusts parameters and retests to ensure that the test pressure is fully applied to the physical memory chips, thereby improving the authenticity of the test performance data by more than 90%.

[0054] Second, the module directly configures the underlying parameters of the memory controller and simulates extreme environments. By securely mapping the memory-mapped input / output register space, the module bypasses the hardware parameter control permissions of the basic input / output system and the operating system, enabling dynamic configuration of parameters such as memory timing, refresh mechanism, and error check code mode, simulating extreme hardware conditions. The system parses the configuration space of the high-speed peripheral interconnect bus to locate the base address of the memory controller's memory-mapped input / output, and maps it to the virtual space of the test process through the kernel-mode ioremap interface. It is set to a permission isolation mode of kernel-mode writable and user-mode read-only, allowing only the system-controlled interface to initiate parameter configuration operations, balancing functional flexibility and system stability. The system supports independent distribution of configuration parameters by memory rank level and memory logical storage block partition. By writing to the corresponding function registers, the system adjusts the memory refresh control parameters, simulating conditions such as insufficient refresh frequency and address conflict refresh, triggering data retention-like latent faults. The system modifies the timing configuration registers to adjust timing parameters such as CL, tRCD, and tRP, approaching the physical operating limits of the memory hardware. The system adjusts the error check code control register, switches the check operation mode, and injects controllable faults to verify the platform's hardware fault tolerance capabilities. After the parameters are written, the system initiates a timing retraining process for the memory controller. After the hardware handshake is complete, the register values ​​are read back to verify parameter consistency, preventing parameter failures from distorting the test scenario. The system supports dynamic iterative parameter tuning at preset step sizes during testing, automatically scanning hardware fault thresholds to trigger marginal latent faults, improving defect detection coverage by over 35%. This module also establishes a communication link with the baseboard management controller, collecting real-time hardware metrics such as memory power consumption and temperature, and pushing them to the test engine layer.

[0055] The test engine layer is the core execution unit of the system, located between the hardware abstraction layer and the control interface layer. Based on the direct access channel and partition mapping capabilities provided by the hardware abstraction layer, this layer realizes intelligent matching and scheduling of algorithms and memory partitions and parallel execution of multiple processes, taking into account both test efficiency and fault detection capabilities. Each sub-module within the layer completes data interaction through the internal application programming interface, and the data interaction latency between modules does not exceed one millisecond.

[0056] The test engine layer includes the following modules.

[0057] The first module is the parallel test scheduler. This module's functions include algorithm-memory region matching decisions, shielding against operating system process scheduling interference, receiving hardware information tables and partition address tables pushed by the hardware abstraction layer, and combining these with user-preset test objectives to determine the mapping relationship between test algorithms and memory regions. It then completes task allocation and parallel scheduling, shielding against timing interference caused by operating system process scheduling. The system calculates the optimal number of test processes based on the number of CPU cores using a process scheduling affinity function, binding each test process to an independent CPU core. This restricts cross-core scheduling migration, avoids timing fluctuations caused by operating system process context switching, and ensures test load stability. The scheduler automatically selects the optimal memory region allocation strategy based on three dimensions: test objective priority, memory hardware topology, and algorithm characteristics, and operates in conjunction with the hardware abstraction layer's partition mapping capabilities. The efficiency-first mode is suitable for mass production rapid testing scenarios. It adopts a partitioned parallel mapping strategy, allocating different test algorithms to independent memory channels or memory logical storage block partitions. Each algorithm's memory access path is physically isolated, eliminating bus contention and block access conflicts, maximizing memory bandwidth and multi-core computing power, and improving test efficiency by over 60%. In this mode, performance indicators are free from algorithm cross-interference, resulting in higher data accuracy. The fault coverage priority mode is suitable for reliability verification scenarios. It employs a same-region overlay mapping strategy, superimposing algorithms with complementary addressing patterns and data patterns onto the same memory block. Through a combination of sequential and jump addressing, it forms a composite hardware stimulus, triggering edge failure scenarios that a single algorithm cannot cover, improving defect detection coverage by over 30%. The low-power balancing mode is suitable for routine testing scenarios. It uses a partitioned block alternating write strategy, with two algorithms writing to different memory blocks in a time-sharing manner. This avoids large-scale bit flips in a single chip, reducing peak dynamic power consumption by over 25% while maintaining fault detection capabilities. The system provides a manual configuration entry, supporting user-defined algorithms and memory region mapping rules to adapt to specific needs. The scheduler monitors process and partition test progress in real time, dynamically splitting and migrating high-load process tasks to achieve load balancing across the entire platform.

[0058] Second, it features a multi-algorithm executor. The module has a built-in library of memory testing algorithms covering all categories. It receives task instructions and partition mapping information from the parallel test scheduler, initiates the corresponding test algorithm in the specified memory area, and completes memory read / write and data verification according to a preset sequence. The module supports concurrent execution of multiple algorithms, allowing for the execution of differentiated algorithms in different partitions or the overlay of complementary algorithms within the same partition. The module provides real-time feedback on the algorithm's running status. Upon receiving a fault signal, it pauses testing in the corresponding area while preserving the on-site data, without affecting the operation of other partitions.

[0059] Thirdly, there is the real-time monitoring module. This module collects hardware and software performance metrics synchronously at a fixed sampling period of ten milliseconds. Hardware metrics include memory power consumption, temperature, and error check code counts, while software metrics include process running status, algorithm execution progress, and memory access latency. The module pushes abnormal data to the error handling module and statistical data to the result generation module.

[0060] Fourth is the error handling module. After receiving the fault data pushed by the monitoring module, the module parses information such as fault type, physical address, and associated test algorithm, retains the original data of the fault scene, instructs the corresponding process to suspend the test task in the fault area, and pushes all fault information to the result generation module.

[0061] The control interface layer is the user interaction and result output layer, located outside the test engine layer. It is responsible for receiving user commands, parsing parameters, managing the test process, and outputting results. It provides functions such as command line interaction, running logs, and reports. Sub-modules within the layer transmit information through the data bus.

[0062] The control interface layer includes the following modules: First, a parameter parsing and control module. This module supports command-line parameter configuration, allowing users to customize parameters such as test run mode, target memory range, number of parallel processes, test duration, and fault judgment threshold. After parsing user commands, the module generates a standardized task configuration table and pushes it to the parallel test scheduler. It also supports remote control of test start, stop, pause, and restart, achieving full-process management. Second, a log recording module. This module records all test process data in real time, covering parameter configuration, process status, dynamic changes in hardware indicators, and fault information. Logs are output in a hierarchical manner, categorized as general information, warning information, and error information. Logs can be saved to local files or output via hardware serial port for easy process traceability and fault diagnosis. Third, a result generator. This module summarizes statistical data from the real-time monitoring module and fault data from the error handling module, and generates a test report through visualization processing. The report includes a fault distribution map, performance trend chart, hardware indicator record table, and error check code timing analysis table, marking the physical address, type, and frequency of faults, and displaying the patterns of memory access latency and throughput changes. The system outputs test conclusions based on preset rules, marking the memory's pass / fail status, fault level, and location suggestions. The report supports export in PDF and HTML formats and can output conclusions via serial port.

[0063] Please see Figure 2The Hardware Abstraction Layer (HAL) connects to the physical hardware via a hardware bus interface, pushes hardware information to the Test Engine Layer, and receives hardware control commands. The Test Engine Layer interacts bidirectionally with the HAL and Control Interface Layers via a software application programming interface (API), receiving task commands and providing feedback on running status and statistical data. The Control Interface Layer receives external commands through a user interface, pushes parsed task commands, receives test data, and generates visual reports. The entire system forms a closed-loop chain with sequential linkage between the user, Control Interface Layer, Test Engine Layer, HAL, and hardware devices, without external program dependencies, and can be deployed and run stably independently.

[0064] Based on the aforementioned memory stress testing system, the corresponding testing method is divided into five stages: hardware initialization, memory test area configuration, parallel test execution, error detection and handling, and result analysis and report generation. Each stage is executed sequentially. Please refer to [link to details]. Figure 3 .

[0065] I. Hardware Initialization Phase. This phase is used for basic information collection and runtime environment setup, and includes four steps.

[0066] 1. Hardware Parameter Acquisition and Architecture Identification. Execution requires the system to power on and start, with no other processes occupying hardware resources. The system calls architecture identification instructions through the hardware abstraction layer architecture detection module. For x86 architecture, this uses the processor identifier instruction; for ARM architecture, it uses the multiprocessor identifier register; and for RISC-V architecture, it uses the vendor identifier read instruction. Parameters such as the number of processor cores, number of memory channels, total physical memory, memory controller model, error check code enable status, and baseboard management controller communication status are collected, generating a hardware information table. If parameter acquisition fails, such as when the baseboard management controller communication is interrupted, the system triggers a hardware alarm and terminates initialization, indicating a hardware connection abnormality.

[0067] 2. Driver Loading and Hardware Adaptation. Execution is contingent upon successful hardware parameter acquisition. The driver adaptation module matches the underlying driver from the device's built-in driver library based on the processor architecture type indicated in the hardware information table, completing loading and initialization. The system simultaneously checks memory module compatibility, verifying the compatibility of specifications such as fourth-generation double data rate memory, fifth-generation double data rate memory, and low-power double data rate memory. Incompatible modules are recorded as exceptions, and the corresponding memory channel is marked; subsequent tests automatically skip this channel.

[0068] 3. Test Parameter Verification. Execution is contingent upon driver loading completion. The control interface layer parameter parsing module reads user-configured parameters; if no configuration is available, default parameters are loaded. Default parameters include full memory testing, the number of parallel processes equaling the number of CPU cores, a test duration of 30 minutes, and a dual-algorithm mode combining the enhanced March algorithm with Gray code sequences. The system verifies parameter validity according to rules, including that the test memory capacity does not exceed 80% of available physical memory, the number of processes does not exceed the number of CPU cores, and the test duration is not less than 5 minutes. If parameters are invalid, the system returns an error message and correction suggestions, requiring reconfiguration and re-verification.

[0069] 4. Process and Communication Mechanism Initialization. Execution condition: Parameter validation passes. The system creates a main test process and N worker test processes, where N equals the number of CPU cores. The main process is responsible for scheduling and global management, while the worker processes execute test tasks. The system establishes a pipe communication mechanism between the main process and worker processes to achieve real-time instruction and data interaction. Simultaneously, it initializes the memory mapping module to complete the address mapping from physical memory to user space and initiates the CPU cache isolation mechanism.

[0070] II. Memory Test Area Configuration Phase. This phase is used to limit the test scope and ensure test independence, and includes two steps.

[0071] 1. Memory Region Allocation and Mapping. Execution requires the completion of the aforementioned initialization process. The memory mapping module, based on the user-configured test scope, divides contiguous physical memory regions according to memory channels and logical memory storage blocks. Through memory mapping combined with direct access mode and a fixed address mapping identifier mechanism, it maps the physical addresses of each partition to the user space of the corresponding working process. Each process corresponds to an independent partition, avoiding memory access conflicts between processes. The system records partition address information, generates a memory partition table, and pushes it to the parallel test scheduler.

[0072] 2. Memory Attribute Configuration. Execution is contingent upon memory region mapping completion. The system calls the memory permission configuration function to configure the permissions of the test memory region, retaining only read and write permissions and disabling execution permissions to prevent malicious code injection. The system calls the global memory locking function to initiate the memory locking mechanism, calling the system interface to disable the corresponding memory region swapping function, ensuring that the test memory remains resident in physical memory throughout its entire lifecycle, preventing the operating system from swapping it to virtual memory, and circumventing system memory management intervention.

[0073] This step employs a layered, precise configuration combined with a two-dimensional closed-loop verification architecture to achieve strong constraints on memory attributes from two dimensions, preventing global configuration from affecting the normal operation of the system, as detailed below.

[0074] First, memory permission configuration enables page table-level execution permission blocking. This configuration applies to the virtual memory region and kernel page table entries within the test process's virtual address space. The memory permission configuration function is called, passing in the partition address range and read / write permission mask. The kernel traverses the page table entries within the target range, clearing the prohibition-of-execution bits, thus blocking the code execution path at the underlying level. This method allows for independent permission configuration per partition, adapting to the differentiated needs of various algorithms. The system reads the memory mapping statistics file in the process directory in real time to verify permission status, intercepting unauthorized modifications and improving protection reliability.

[0075] Secondly, memory locking and swapping are disabled to achieve a two-layer interception and persistent memory protection. This solution employs a dual mechanism of process-level memory locking combined with system-level swapping shielding, blocking system memory management intervention from the execution path and policy rules. Process-level locking operates on the entire virtual memory mapping of the process, calling the global memory locking function and passing in the current and future memory identifiers to configure virtual memory locking flags for the process memory. The corresponding physical memory pages are removed from the system's reclamation list and do not participate in regular reclamation. This solution is compatible with the partitioned locking mode of single-region memory locking functions, allowing locking only the target region and reducing resource consumption. System-level shielding operates on the control group memory subsystem parameters and virtual memory interface, placing the test process in an isolated control group, setting the memory swapping priority to zero, aligning memory swapping quotas with physical memory quotas, and blocking memory swapping paths at the kernel level. This dual mechanism can maintain stable memory access timing under high system load scenarios, improving the reliability of test data.

[0076] After all configurations are complete, the system reads the memory mapping manifest file and memory mapping statistics file in the process directory, verifies partition permissions, lock flags, and swap attributes, and proceeds to the next step after successful verification.

[0077] III. Parallel Test Execution Phase. This phase ensures efficient and stable test execution and includes three steps.

[0078] 1. Task allocation and process binding. Execution is contingent upon complete memory configuration. The parallel test scheduler allocates partitions to corresponding worker processes based on the memory partition table and hardware information table. The system binds each worker process to an independent CPU core using process scheduling affinity functions, setting the highest scheduling priority to avoid resource contention by background processes. The scheduler issues task instructions, such as test algorithms and durations, to the worker processes.

[0079] 2. Parallel execution of multiple algorithms. Execution is contingent upon task allocation completion. Each worker process synchronously starts a preset algorithm, performing memory read / write and verification operations in a fixed sequence. The enhanced March algorithm sequentially completes ascending address scan, write 0, read 0, write 1, read 1, write 0, then descending address scan, read 0, write 1, read 1, write 0, read 0. Each process synchronously runs a Gray code test sequence, based on an adaptive scheduling mechanism. This mechanism combines intelligent perception and manual customization capabilities, automatically identifying constraints to match the optimal strategy, and also supporting user-configured parameters. The mechanism includes two adjustable modes: partitioned parallelism and intra-partition overlay, adapted to time-sensitive and deep reliability scenarios respectively. Throughout the test, the system collects real-time data on memory access latency, throughput, fault address, and fault type for subsequent analysis and troubleshooting.

[0080] 3. Dynamic load balancing. Execution conditions are normal test execution and no fault triggering. The parallel test scheduler collects the CPU utilization and memory bandwidth utilization of each process in real time. When the process load reaches 90% or above, a portion of its partitions are split and distributed to idle processes with a load of 70% or below, achieving full process load balancing.

[0081] IV. Error Detection and Handling Phase. This phase is used for fault detection and categorized handling, and includes three steps.

[0082] 1. Real-time fault monitoring. The execution condition is a sampling period of ten milliseconds during test execution. The real-time monitoring module synchronously collects hardware and software indicators. When it detects error check code faults, bit flip faults, or when the memory temperature reaches 85 degrees Celsius or power consumption exceeds the threshold, it triggers a fault signal and synchronously records all fault information.

[0083] 2. Error Injection Verification. The execution condition is that there are no actual hardware failures during the test and the test duration is more than halfway complete. The system actively injects a controllable single-bit error check code fault to verify fault detection and response capabilities. If an anomaly is detected, the information is recorded and the test continues. The verification results are finally noted in the report.

[0084] 3. Emergency Fault Handling. The execution condition is a system-triggered hardware fault signal. The error handling module instructs the corresponding process to suspend testing in the faulty area, retaining 1000 bytes of original data before and after the fault address, along with the algorithm execution status. The scheduler migrates unfinished tasks to idle processes, ensuring the overall process remains uninterrupted. When the fault frequency reaches five times per minute or more, it is considered a serious fault, terminating the corresponding memory channel test, while the remaining channels operate normally.

[0085] V. Results Analysis and Report Generation Stage. This stage is used for data aggregation and standardized output, and includes two steps: 1. Data Statistical Analysis. Execution condition: Normal test completion or voluntary termination. The results generator aggregates performance and fault data, calculates indicators such as fault occurrence rate, test coverage, average access latency, peak bandwidth, and average power consumption, classifies and statistically analyzes faults by type, address, and time, and identifies fault distribution patterns. 2. Report Generation and Output. Execution condition: Data analysis completion. The system generates a report containing configuration information, operation logs, fault details, performance indicators, and time-series curves. Based on rules, it outputs pass / fail conclusions and location suggestions. The report supports PDF and HTML export, and conclusions can be output via serial port.

[0086] As described above, this embodiment improves memory read / write timing stability and test result reproducibility by employing an architecture-adaptive driver, exclusive mapping between user space and physical memory, shielding operating system memory mechanisms, and a process kernel-bound parallel testing architecture. This avoids test interference from system scheduling, memory swapping, and background threads. The solution is compatible with multiple processor architectures and memory specifications, supports flexible testing modes such as algorithm partitioning and parallel processing, and overlapping of the same partition, and is suitable for scenarios such as mass production screening and reliability verification. Through dynamic load balancing and tiered fault handling, hardware resource usage is balanced while ensuring test continuity. The multi-dimensional data collected throughout the process provides a complete reference for memory performance evaluation and fault location.

[0087] The following describes a memory testing device provided in an embodiment of this application. The memory testing device described below can be referred to in conjunction with other embodiments described herein.

[0088] See Figure 4 As shown in the figure, this application discloses a memory testing device, including: Loading module 401 is used to respond to a test request, identify the architecture type of the device processor, and load the corresponding driver; The mapping module 402 is used to establish the binding relationship between each test process in user space and each core of the device processor, as well as the exclusive mapping relationship between each test process and each memory partition in the physical memory area of ​​the device processor, and to prohibit the operating system layer from operating on the physical memory area. Test module 403 is used to control the parallel execution of different test algorithms by various test processes to test the corresponding memory partitions according to the binding relationship and exclusive mapping relationship.

[0089] In one implementation, the loading module is specifically used for: The target instruction is invoked to collect the number of processor cores, number of memory channels, total physical memory, memory controller model, error check enable status, and communication status of the device, thereby obtaining a hardware information table; Identify the architecture type according to the hardware information table; The system queries the preset driver library for the driver corresponding to the architecture type and loads the found driver.

[0090] In one implementation, the mapping module is specifically used for: The objective function is used to establish the binding relationship between each test process and each core.

[0091] In one implementation, the mapping module is specifically used for: Divide the physical memory area into various memory partitions; The physical address and direct access permissions of each memory partition are forcibly bound to the corresponding test process to establish an exclusive mapping relationship.

[0092] In one implementation, the mapping module is specifically used for: Each memory partition is marked as locked, so that the operating system layer prohibits the reclamation operation of the corresponding user memory area based on the locked status.

[0093] In one implementation, it further includes: The monitoring module is used to monitor the load information of each test process; if the load information of any test process exceeds the limit, the memory partition corresponding to that test process will be split and distributed to other test processes whose load information does not exceed the limit.

[0094] In one implementation, it further includes: The error injection module is used to inject error verification data during the test and collect memory fault information. If the analysis of memory fault information confirms an unrecoverable fault in any memory partition, the test of that memory partition is suspended, while the test process for other memory partitions is maintained.

[0095] For more detailed information on the working process of each module and unit in this embodiment, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0096] As can be seen, this embodiment provides a memory testing device that can reduce the impact of the operating system on memory testing and is compatible with various hardware devices with different architectures and diverse hardware testing scenarios.

[0097] The following describes an electronic device provided by an embodiment of this application. The electronic device described below can be referred to in conjunction with other embodiments described herein.

[0098] See Figure 5 As shown in the figure, an embodiment of this application discloses an electronic device, including: Memory 501 is used to store computer programs; Processor 502 is configured to execute the computer program to implement the method disclosed in any of the above embodiments.

[0099] Furthermore, embodiments of this application also provide an electronic device. The aforementioned electronic device can be, for example,... Figure 6 The server shown can also be as follows: Figure 7 The terminal shown. Figure 6 and Figure 7 These are all diagrams illustrating the structure of an electronic device according to an exemplary embodiment. The content in the diagrams should not be considered as any limitation on the scope of this application.

[0100] Figure 6 This is a schematic diagram of a server structure provided in an embodiment of this application. The server may specifically include: at least one processor, at least one memory, a power supply, a communication interface, an input / output interface, and a communication bus. The memory stores a computer program, which is loaded and executed by the processor to implement the relevant steps in the memory testing disclosed in any of the foregoing embodiments.

[0101] In this embodiment, the power supply is used to provide operating voltage for each hardware device on the server; the communication interface can create a data transmission channel between the server and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0102] In addition, the memory, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored on it include operating system, computer programs and data, etc., and the storage method can be temporary storage or permanent storage.

[0103] The operating system manages and controls the various hardware devices and computer programs on the server to enable the processor to perform operations and processes on the data in the memory. It can be Windows Server, Netware, Unix, Linux, etc. In addition to computer programs capable of performing the memory testing methods disclosed in any of the foregoing embodiments, the computer programs may further include computer programs capable of performing other specific tasks. The data may include application update information and application developer information.

[0104] Figure 7 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application. The terminal may include, but is not limited to, a smartphone, tablet computer, laptop computer, or desktop computer.

[0105] Typically, the terminal in this embodiment includes a processor and a memory.

[0106] The processor may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor can be implemented using at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), or PLA (Programmable Logic Array). The processor may also include a main processor and coprocessors. The main processor, also known as the CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor may also include an AI (Artificial Intelligence) processor, which handles computational operations related to machine learning.

[0107] The memory may include one or more computer non-volatile storage media, which may be non-transitory. The memory may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory is used to store at least the following computer program, which, after being loaded and executed by the processor, is capable of implementing the relevant steps in the memory testing method executed on the terminal side as disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory may also include operating systems and data, and the storage method may be temporary or permanent storage. The operating system may include Windows, Unix, Linux, etc. The data may include, but is not limited to, application update information.

[0108] In some embodiments, the terminal may further include a display screen, an input / output interface, a communication interface, a sensor, a power supply, and a communication bus.

[0109] Those skilled in the art will understand that Figure 7 The structure shown does not constitute a limitation on the terminal and may include more or fewer components than illustrated.

[0110] The following describes a non-volatile storage medium provided in an embodiment of this application. The non-volatile storage medium described below can be referred to in conjunction with other embodiments described herein.

[0111] A non-volatile storage medium is provided for storing a computer program, wherein the computer program, when executed by a processor, implements the memory testing method disclosed in the foregoing embodiments. The non-volatile storage medium is a computer-readable non-volatile storage medium, which, as a carrier of resource storage, can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored thereon include an operating system, computer programs, and data, and the storage method can be temporary storage or permanent storage.

[0112] The following describes a computer program product provided by an embodiment of this application. The computer program product described below can be referred to in conjunction with other embodiments described herein.

[0113] A computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of the aforementioned disclosed memory testing method.

[0114] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium for storing a computer program that, when executed by a processor, implements the steps in any of the above embodiments.

[0115] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0116] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0117] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of non-volatile storage medium known in the art.

[0118] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A memory testing method, characterized in that, include: In response to a test request, identify the device processor's architecture type and load the corresponding driver; Establish a binding relationship between each test process in user space and each core of the device processor, as well as an exclusive mapping relationship between each test process and each memory partition in the physical memory area of ​​the device processor, and prohibit the operating system layer from operating on the physical memory area; Based on the binding relationship and the exclusive mapping relationship, control each test process to run different test algorithms in parallel to test the corresponding memory partition.

2. The method according to claim 1, characterized in that, Identify the device processor's architecture type and load the corresponding driver, including: The target instruction is invoked to collect the number of processor cores, number of memory channels, total physical memory, memory controller model, error checking enable status, and communication status of the device, thereby obtaining a hardware information table; Identify the architecture type according to the hardware information table; The system queries the preset driver library for the driver corresponding to the architecture type and loads the found driver.

3. The method according to claim 1, characterized in that, Establishing the binding relationship between each test process in user space and each core of the device processor, including: The objective function is used to establish the binding relationship between each test process and each core.

4. The method according to claim 1, characterized in that, The exclusive mapping relationship between each test process and each memory partition in the physical memory area of ​​the device processor includes: The physical memory area is divided into various memory partitions; The physical address and direct access permissions of each memory partition are forcibly bound to the corresponding test process to establish an exclusive mapping relationship.

5. The method according to claim 1, characterized in that, Disallowing the operating system layer from operating the physical memory area includes: Each memory partition is marked as locked, so that the operating system layer prohibits the reclamation operation of the corresponding user memory area based on the locked status.

6. The method according to any one of claims 1 to 5, characterized in that, Also includes: Monitor the load information of each test process; If the load information of any test process exceeds the limit, the memory partition corresponding to that test process will be split and allocated to other test processes whose load information does not exceed the limit.

7. The method according to any one of claims 1 to 5, characterized in that, Also includes: Error verification data is injected during the testing process, and memory fault information is collected. If the analysis of the memory fault information confirms an unrecoverable fault in any memory partition, then the testing of that memory partition is paused, while the testing process for other memory partitions continues.

8. A memory testing device, characterized in that, include: The loading module is used to respond to test requests, identify the architecture type of the device processor, and load the corresponding driver; The mapping module is used to establish the binding relationship between each test process in user space and each core of the device processor, as well as the exclusive mapping relationship between each test process and each memory partition in the physical memory area of ​​the device processor, and to prohibit the operating system layer from operating on the physical memory area. The testing module is used to control each testing process to run different testing algorithms in parallel to test the corresponding memory partition according to the binding relationship and the exclusive mapping relationship.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the method as described in any one of claims 1 to 7.

10. A non-volatile storage medium, characterized in that, Used to store a computer program, wherein the computer program, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images