Processor testing system and electronic device

Abstract

The application discloses a processor test system and electronic equipment. The processor test system comprises a control module configured to receive a test task request, determine an initial test flow based on the test task request, and initialize a test environment; the test environment is used for testing a processor; an identification strategy module configured to acquire hardware identification information of the processor, and match a strategy template corresponding to the processor in a preset strategy library based on the hardware identification information; the strategy template comprises test configuration parameters; the control module is connected with the identification strategy module, and the control module is further configured to determine a test flow based on the hardware identification information and the initial test flow; a configuration module connected with the identification strategy module and configured to configure the test environment based on the test configuration parameters; and an execution module configured to test the processor in the configured test environment based on the test flow, and obtain test data.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of server processor testing, and particularly relates to a processor testing system and an electronic device. BACKGROUND

[0002] With the continuous improvement of processor performance in servers and computing devices, different processor platforms differ in micro-architecture, instruction set extension, cache hierarchy, memory configuration, and firmware and operating system configuration. When carrying out performance, stability and function tests on different processor platforms, the selection of test tools, compilation optimization options, running parameters and test environment configuration all need to be adjusted according to the different processors under test.

[0003] In the existing processor testing method, the test tools, test parameters and test environment configuration items are usually configured in a pre-set manner. When facing different processors, the test personnel need to manually identify the model and related hardware parameters of the processor, and then select the corresponding test tools and test parameters according to the processor platform, and configure the basic input / output system, operating system and test tool running environment. For the scene where the same test system needs to carry out repeated tests for different processor platforms, the above configuration process needs to be manually executed by the test personnel multiple times, resulting in low test efficiency and complex test process.

[0004] At present, there is still a lack of a solution that can automatically identify Advanced Micro Devices (AMD) processor platforms and adaptively match the optimal test strategy. SUMMARY

[0005] The present application provides a processor testing system and an electronic device to at least solve the problems of low test environment configuration efficiency and inability to adaptively adapt for different AMD processor platforms in the related art.

[0006] The application provides a processor test system, comprising a control module, an identification strategy module, a configuration module and an execution module, wherein the control module is configured to receive a test task request, determine an initial test flow based on the test task request, and initialize a test environment; the test environment is used for testing the processor; the identification strategy module is configured to acquire hardware identification information of the processor, and match a strategy template corresponding to the processor in a preset strategy library based on the hardware identification information; the strategy template comprises test configuration parameters; the control module is connected with the identification strategy module, and the control module is further configured to determine a test flow based on the hardware identification information and the initial test flow; the configuration module is connected with the identification strategy module, and is configured to configure the test environment based on the test configuration parameters; the execution module is configured to test the processor in the configured test environment based on the test flow, and obtain test data; the test data comprises at least one of a test log, performance counter data and system monitoring indicators.

[0007] The application further provides an electronic device comprising the processor test system.

[0008] The application further provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program; when the computer program is executed by a processor, the steps of the processor test method are implemented.

[0009] The application further provides a computer program product, comprising a computer program; when the computer program is executed by a processor, the steps of the processor test method are implemented.

[0010] The application automatically acquires hardware identification information of a processor and matches a corresponding strategy template in a preset strategy library by setting an identification strategy module, and automatically completes end-to-end test environment configuration from a firmware layer to a system layer to an application layer based on the strategy template by setting a configuration module, while a control module dynamically adjusts a test process according to the hardware identification information, so that manual identification of a Central Processing Unit (CPU) model and manual configuration of a test environment are not needed; since the application standardizes differences in Basic Input / Output System (BIOS) configuration parameters, kernel tuning parameters, test tool versions and compilation optimization options corresponding to different AMD processor architectures (such as Zen2, Zen3, Zen4, etc.) into strategy templates in advance, and establishes an automatic matching mechanism between hardware identification information and strategy templates, the test system can automatically select and load an optimal configuration scheme according to the platform type of an actual processor under test without human intervention, so that the technical problems of low test efficiency and serious waste of manpower caused by large differences in test environments among different AMD processor platforms and inefficient manual configuration in the prior art can be solved, the technical effects of shortening manual environment configuration time from 2-3 hours to 0.5 hours, eliminating human configuration differences to ensure result consistency, improving processor performance by 5-8%, and realizing test full-process automation are achieved. BRIEF DESCRIPTION OF DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the application, the drawings needed in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0012] Figure 1 A structural schematic diagram of a processor test system according to some embodiments is provided. Figure 2 A structural schematic diagram of an identification strategy module according to some embodiments is provided. Figure 3 A structural schematic diagram of a control module according to some embodiments is provided. Figure 4 A structural schematic diagram of a configuration module according to some embodiments is provided. Figure 5 A structural schematic diagram of an execution module according to some embodiments is provided. Figure 6 A structural schematic diagram of an analysis module according to some embodiments is provided. Figure 7A flowchart of a processor testing method according to some embodiments. DETAILED DESCRIPTION

[0013] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, any other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0014] It should be noted that, in the description of the present application, the terms “comprise”, “contain” or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. The terms “first”, “second” and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0015] In order for 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 drawings and specific embodiments.

[0016] In conjunction with the specific application environment architecture or specific hardware architecture on which the processor testing system and method are executed, the specific application environment architecture or specific hardware architecture is described herein.

[0017] In the existing processor testing method, the configuration items such as test tools, test parameters and test environment are usually configured in a pre-set manner. When facing different processors, the test personnel need to manually identify the model and related hardware parameters of the processor, and then select the corresponding test tools and test parameters according to the processor platform. When testing different processors, this configuration process needs to be performed manually multiple times by the test personnel, resulting in low test efficiency and complex test process.

[0018] On the one hand, although AMD processors have been widely used in the server field, the testing technology for the functions and performance of AMD processors is still not mature. In related technologies, the conventional processor testing technology is basically for Intel processors, and cannot be applied to AMD processors.

[0019] On the other hand, the existing test scheme for AMD processors has great differences among different architecture platforms such as AMD Zen / Zen2 / Zen3 / Zen4, because different BIOS configurations, kernel parameters, test tool versions, etc. are required. Each test needs to manually identify the CPU model, then install the test tool, modify the BIOS parameters, and other environment configuration operations according to the CPU model. Manual configuration of the environment takes a long time, such as more than 2 hours, causing repeated waste of manpower.

[0020] Therefore, embodiments of the present application provide a processor testing system and method. Referring to Figure 1 FIG. 1 is a structural schematic diagram of a processor testing system according to some embodiments.

[0021] The processor testing system 100 includes a control module 10, an identification strategy module 20, a configuration module 30, and an execution module 40.

[0022] The control module 10 is configured to receive a test task request, determine an initial test flow based on the test task request, and initialize a test environment; the test environment is used to test the processor.

[0023] The identification strategy module 20 is configured to obtain hardware identification information of the processor, and match a strategy template corresponding to the processor in a preset strategy library based on the hardware identification information; the strategy template includes test configuration parameters.

[0024] The configuration module 30 is connected with the identification strategy module 20, and is configured to configure the test environment based on the test configuration parameters.

[0025] The execution module 40 is configured to test the processor in the configured test environment and obtain test data. The test data includes at least one of a test log, performance counter data, and system monitoring indicators.

[0026] The control module 10 is connected with the identification strategy module 20, and the control module 10 is further configured to determine a test flow based on the hardware identification information and the initial test flow.

[0027] The four modules cooperate to realize the full-process automation from hardware identification, strategy matching, environment configuration to test execution. Since the identification strategy module 20 is configured to automatically obtain the hardware identification information of the processor and match the corresponding strategy template in the preset strategy library, the configuration module 30 is configured to automatically complete the test environment configuration based on the strategy template, and the control module 10 dynamically adjusts the test process according to the hardware identification information, manual identification of the CPU model and manual configuration of the test environment are not required, the test environment configuration time is greatly shortened, the manual environment configuration time of 2-3 hours is shortened to 0.5 hours, the human configuration difference is eliminated to ensure the consistency of the results, the performance of the processor is improved by 5-8%, and the technical effects of test full-process automation are realized. Thus, the technical problems of low test efficiency and serious waste of manpower caused by large test environment difference between different processor platforms, manual configuration inefficiency in the related art are effectively solved.

[0028] Moreover, since the identification strategy module 20 can automatically identify the processor model and match the corresponding strategy template, manual query of the CPU model and manual selection of the corresponding test configuration parameters are not required, configuration errors caused by manual operation are avoided, and the speed and accuracy of strategy matching are greatly improved.

[0029] In addition, the control module 10 interacts with the identification strategy module 20, dynamically adjusts the work flow branch (such as selecting the corresponding Zen4 strategy library and loading the optimized configuration for EPYC 9004) according to the hardware identification information (such as identifying that the current platform is the EPYC 9004 series processor of Zen4 architecture) and the initial work flow to determine the work flow, and realizes adaptive testing. Thus, the same set of test system can adapt to AMD processors of different architectures from Zen2 to Zen4, without the need to design a test process for each processor platform, and the versatility and scalability of the test system are greatly improved.

[0030] In some embodiments, referring to Figure 2 is a structural schematic diagram of an identification strategy module provided according to some embodiments. The identification strategy module 20 includes an identification unit 21, a strategy management unit 22 and a first database 23.

[0031] The identification unit 21 is configured to obtain basic hardware parameter information of the processor, and perform normalization processing on the basic hardware parameter information to generate hardware identification information.

[0032] In this embodiment, the identification unit 21 is further configured to, in the case that the basic hardware parameter information is missing, obtain supplementary hardware parameter information based on field replaceable unit data or an application programming interface; and perform normalization processing on the basic hardware parameter information and the supplementary hardware parameter information to generate the hardware identification information.

[0033] Exemplarily, the identification unit 21 acquires basic hardware parameter information and / or supplementary hardware parameter information by executing a hardware detection command in an in-band manner and an out-of-band manner. The in-band manner includes, for example, a Secure Shell (SSH), and the out-of-band manner includes, for example, an Intelligent Platform Management Interface (IPMI) or Redfish. The acquired information includes a CPU model, a core number, a thread number, a Non-Uniform Memory Access (NUMA) node number, a memory configuration, a BIOS version, and the like. Subsequently, the information is normalized to generate standardized hardware identification information.

[0034] The policy management unit 22, connected with the identification unit 21, is configured to match a policy template corresponding to the processor according to the hardware identification information and the test type in a preset policy library. The policy template includes at least one of a test tool selection, a compilation optimization option, a running parameter, an environment variable, and a kernel parameter tuning suggestion. The test type is determined based on the task parameter provided by the control module 10.

[0035] The policy management unit 22 receives the hardware identification information generated by the identification unit 21 and the test type parameter provided by the control module 10, and performs matching in the preset policy library. The policy library is pre-installed with policy templates for different AMD processor architectures and is defined in a JSON / YAML format.

[0036] In this embodiment, the policy management unit 22 also provides a version control function to support the addition, deletion, modification, and query of the policy template and historical backtracking. The policy management unit 22 can not only automatically match the policy template according to the platform identifier and the test type, but also can override or customize the policy template based on user input.

[0037] The first database 23 is used to store at least one of the microarchitecture, the instruction set extension, the cache hierarchy, the power consumption range, the supported memory type, the supported memory frequency, the known errata, the compatibility list, and the optimization parameter information of the processor.

[0038] The first database 23 provides data support for policy generation and keeps synchronization with the AMD official release information through regular updates. When the policy management unit 22 needs to query whether a certain processor supports a specific instruction set, it can quickly retrieve from the first database 23.

[0039] In the management system provided in this application embodiment, by setting up an identification unit 21, a policy management unit 22, and a first database 23, the system achieves accurate acquisition of processor hardware information, intelligent matching of policy templates, and centralized storage and management of hardware parameter data, further improving the system's adaptability to different AMD processor platforms and the accuracy of policy matching.

[0040] Furthermore, the identification unit 21 provided in this embodiment employs a multi-level detection mechanism: firstly, it quickly obtains basic hardware parameter information using tools such as DMIDecode and LSCPU. If the basic hardware parameter information is incomplete, it reads FRU data through IPMI or calls the vendor's API to obtain supplementary hardware parameter information. The basic hardware parameter information and / or supplementary hardware parameter information are normalized to generate standardized hardware identification information for subsequent policy template matching.

[0041] In some embodiments, see Figure 3 This is a schematic diagram of a control module according to some embodiments. The control module 10 includes a test control unit 11, a workflow unit 12, and a task scheduling unit 13.

[0042] The test control unit 11 is configured to receive test task requests, generate task parameters based on the test task requests, and initialize the test environment.

[0043] The test control unit 11 serves as the entry point for the control module 10, providing a unified API interface to receive test task requests from users or the upper-level management platform. After receiving a test task request, the test control unit 11 parses the task parameters, determines the test process, and initializes the test environment.

[0044] For example, the test control unit 11 is used to parse the request body to generate task parameters such as target IP, test type, and priority, and to initialize the test environment by creating a task directory and assigning task IDs.

[0045] Workflow unit 12, connected to test control unit 11, is configured to determine the test process based on task parameters or user input information, and to adjust the test process based on hardware identification information.

[0046] In this embodiment, workflow unit 12 determines the initial test process based on the test type, and then dynamically adjusts the initial test process based on hardware identification information to determine the final test process. Workflow unit 12 is also configured to have a retry mechanism, timeout control, and exception handling strategy to ensure the robustness of the test process.

[0047] For example, when the hardware identification information indicates that the platform is a Zen4 architecture, a specific optimization step is added to the testing process; when the platform is a Zen3 architecture, a different optimization branch is selected.

[0048] The task scheduling unit 13, connected to the test control unit 11, is configured to generate executable units based on test task requests and allocate the executable units to the corresponding test nodes.

[0049] In this embodiment, the task scheduling unit 13 decomposes the test task into executable sub-units and monitors the CPU utilization, memory utilization, disk I / O, and other resource usage of each computing node in real time, and determines the task allocation logic based on the resource situation. The task scheduling unit 13 supports priority queues, resource reservation, and load balancing, and also supports breakpoint resume and task dependency management.

[0050] In this embodiment, the test control unit 11 integrates the three steps of receiving, parsing, and initializing into one unit. Users only need to make a single API call to submit test tasks and automatically prepare the environment, simplifying the user operation process. This avoids the tedious manual setup of the test environment and improves the startup efficiency of test tasks. The workflow unit 12 can automatically adjust specific steps in the test process based on hardware identification information representing the processor model or platform, eliminating the need to write different test process scripts for each processor and significantly reducing the complexity of test process maintenance. The task scheduling unit 13 can intelligently allocate test tasks based on the real-time resource usage of each computing node, avoiding single-point resource overload and resource idleness, and improving the overall resource utilization of the test cluster.

[0051] In some embodiments, see Figure 4 This is a schematic diagram of a configuration module according to some embodiments. The configuration module 30 includes an environment configuration unit 31, a firmware configuration unit 32, an operating system configuration unit 33, and a test tool deployment unit 34.

[0052] Environment configuration unit 31 is configured to generate a configuration task list based on test configuration parameters.

[0053] In this embodiment, the environment configuration unit 31 parses the policy template, generates a list of configuration tasks arranged in the order of dependencies, coordinates the firmware configuration unit 32, the operating system configuration unit 33 and the test tool deployment unit 34, supports the differentiated configuration of servers from different vendors through a plug-in architecture, and thus provides configuration pre-check and rollback mechanisms.

[0054] Firmware configuration unit 32, connected to environment configuration unit 31, is configured to generate basic input / output system setting parameters based on test configuration parameters.

[0055] In this embodiment, the firmware configuration unit 32 includes at least one out-of-band management API from a server vendor to convert abstract parameters in the policy template into BIOS system setting parameters, enabling batch setting and querying of BIOS parameters. The firmware configuration unit 32 also includes a standardized mapping table of BIOS parameters from at least one vendor, which can automatically select the correct BIOS setting item based on the server vendor, eliminating the need to manually search for and input BIOS setting items for servers from different vendors, thus simplifying the BIOS configuration process for cross-vendor servers.

[0056] Operating system configuration unit 33, connected to environment configuration unit 31, is configured to generate system optimization instructions based on policy templates. These system optimization instructions are used to adjust operating system parameters and / or configure the operating system kernel.

[0057] In this embodiment, the operating system configuration unit 33 connects to the target node via SSH, generates and executes system optimization commands based on the policy template, and all operations performed by the system optimization commands are based on the policy template and generate detailed change logs. The operating system configuration unit 33 can automatically convert the optimization parameters in the policy template into executable commands, eliminating the need for manual login to the server and modification of configuration files, thus significantly reducing OS tuning time.

[0058] In this embodiment, the system optimization instructions include at least one of the following: processor scheduling policy, adjusting transparent big pages, disabling address space layout randomization, configuring memory locking limits, and modifying system limits.

[0059] In this embodiment, the system optimization instructions include at least one of the following: kernel module loading instructions, network protocol stack optimization instructions, and disk scheduler adjustment instructions.

[0060] For example, the operating system configuration unit 33 generates and executes the following system optimization instructions based on the policy template: The processor scheduling policy setting instruction sets the CPU scheduling policy to performance mode, ensuring the CPU always runs at its highest frequency during testing; the transparent big page adjustment instruction enables transparent big pages, reducing memory address translation overhead; the ASLR instruction is disabled to eliminate the impact of address space randomization on program execution time; the memory lock limit configuration instruction ensures the test program can lock critical data in physical memory; and the system limit modification instruction increases the file handle limit. These optimization instructions eliminate performance interference factors at the operating system level, resulting in more stable and accurate test results, while also allowing the processor performance to be fully utilized.

[0061] For example, the operating system configuration unit 33 also generates kernel module loading instructions to load the MSR module, enabling the test tool to directly read the CPU performance monitoring registers; network protocol stack optimization instructions to set the TCP congestion control algorithm to BBR to optimize network transmission performance; and disk scheduler adjustment instructions to set the I / O scheduler to none to reduce I / O latency. These optimization instructions can be tailored to the specific characteristics of the test task, further improving test performance.

[0062] The test tool deployment unit 34 is connected to the environment configuration unit 31 and is configured to select the test tool corresponding to the test configuration parameters in the image repository, and generate a test container on the test node to execute test tasks based on the test tool.

[0063] In this embodiment, the test tool deployment unit 34 is also configured to clean up the test containers after the test task is completed. For example, after the test task is completed, the test tool deployment unit 34 automatically performs a container cleanup operation, stops and deletes the containers, releases the occupied resources, and cleans up temporary files and mounted volume data. This ensures that disk space is not continuously occupied in long-term operation scenarios, and each test task is started from a clean environment, avoiding residual data from affecting the results of the next test.

[0064] The test tool deployment unit 34 can encapsulate test tools and their dependent environments using container technology, maintain a private image repository storing different versions of test tool images, and pull the image of the specified version of the test tool to the test node according to the policy template requirements. The deployment process supports silent installation and environment variable injection. Because the test tool deployment unit 34 uses container technology to encapsulate test tools and their dependent environments, the runtime environments of different test tasks are isolated from each other, avoiding tool version conflicts, while ensuring that the test environments running on different physical servers are completely consistent.

[0065] The configuration module 30 receives a policy template provided by the identification policy module 20. This policy template includes test configuration parameters, and the configuration module 30 can automatically configure the test environment based on these parameters. For example, the configuration module 30 sets compiler environment variables according to the compiler optimization options specified in the policy template, writes corresponding parameters into the test configuration file according to the specified number of test replicas, and automatically completes BIOS parameter settings, operating system parameter tuning, and test tool deployment. Because the configuration module 30 can automatically complete the full-stack configuration of the test environment, there is no need for manual modification of BIOS configuration, operating system parameters, and installation of test tools, which significantly shortens the environment configuration time and eliminates inconsistencies caused by manual configuration.

[0066] Furthermore, the environment configuration unit 31 can automatically parse the policy template and generate an ordered list of configuration tasks, avoiding configuration order errors that may be caused by manual judgment of configuration dependencies, and improving the reliability of the configuration process.

[0067] In some embodiments, the operating system configuration unit 33 is further configured to generate an operating system change log; the operating system change log is used to characterize the adjustments made to the operating system by system optimization instructions.

[0068] For example, when executing each system optimization instruction, the operating system configuration unit 33 synchronously records a detailed change log, including the state before the change, the content of the change operation, the operation result, timestamps, and other information. Since the change log records the state comparison before and after each optimization operation, when test results are abnormal, testers can quickly locate whether it is caused by a configuration error of a certain system parameter by consulting the change log, greatly shortening the troubleshooting time.

[0069] In some embodiments, firmware configuration unit 32 is further configured to perform batch settings of basic input / output system settings parameters based on out-of-band management interface.

[0070] For example, firmware configuration unit 32 simultaneously configures the BIOS of multiple test servers equipped with processors via the Redfish out-of-band management protocol, executing BIOS parameter settings in parallel. Because firmware configuration unit 32 utilizes the out-of-band management protocol's characteristic of being unaffected by the operating system state, it can complete BIOS configuration during the PXE boot phase even if the server operating system is not yet installed, while significantly reducing the total configuration time for multiple servers through parallel execution.

[0071] In some embodiments, the firmware configuration unit 32 is configured to record a configuration snapshot before the basic input / output system setting parameters are set, and / or record a configuration snapshot after the basic input / output system setting parameters are set.

[0072] Before performing BIOS configuration, the firmware configuration unit 32 obtains all current BIOS parameters and saves them as a "pre-configuration snapshot". After the configuration is completed, it obtains the changed parameters again and saves them as a "post-configuration snapshot". It automatically compares the differences between the two snapshots to generate a configuration change list. After the test is completed, the BIOS parameters can be restored to the state before the test based on the snapshot, avoiding configuration residue from affecting subsequent tests. It also provides accurate configuration history for troubleshooting.

[0073] In some embodiments, see Figure 5 This is a schematic diagram of the structure of an execution module according to some embodiments. The execution module 40 includes an execution unit 41, a container management unit 42, and a resource scheduling unit 43.

[0074] The execution unit 41 is configured to test the processor in a configured test environment, acquire and parse the processor's test output to generate test data, which facilitates subsequent automated analysis and report generation.

[0075] In this embodiment, the execution unit 41 executes the Standard Performance Evaluation Corporation (SPEC) CPU benchmark test command in the configured test environment, captures and parses the test output in real time, extracts progress information, performance data and error alarms, and converts unstructured test logs into structured test data.

[0076] The container management unit 42 is configured to provide a containerized runtime environment for test tasks.

[0077] In this embodiment, the container management unit 42 creates and manages an independent container runtime environment for each test task, and sets resource limits such as CPU share, memory limit, and disk quota to prevent resource contention.

[0078] In this embodiment, the container management unit 42 is also configured to restart the abnormal container if at least one abnormal container is included among multiple containers, or to migrate the test task running in the abnormal container to other containers among multiple containers.

[0079] The container management unit 42 continuously monitors the health status of all running containers. When an abnormal container status is detected or the test process stops responding, the container is marked as an abnormal container. Then, the container is restarted and the test task is resumed from the point of interruption. Alternatively, a new container is created on another healthy node and the test task is migrated to the new container for execution. This avoids the failure of the entire test task due to container failure, thereby improving the completion rate of the test task and the availability of the system.

[0080] Resource scheduling unit 43 is configured to allocate core and memory nodes based on the resource utilization information of computing nodes and the test characteristics of test tasks.

[0081] In this embodiment, the resource scheduling unit 43 perceives the NUMA topology and resource utilization of the computing nodes in real time. Based on the CPU-intensive or memory-intensive characteristics of the test tasks, it uses a NUMA-aware affinity strategy to allocate tasks to the cores and memory of the same NUMA node, reducing cross-NUMA node access latency and significantly improving test performance on large-scale multi-core processors.

[0082] The resource scheduling unit 43 collaborates with the task scheduling unit 13 of the control module 10 to achieve finer-grained hardware resource allocation. The resource scheduling unit monitors the NUMA topology, core idle status, and memory bandwidth utilization of each computing node in real time, and allocates core and memory nodes according to the characteristics of the test task. Furthermore, based on a NUMA-aware affinity strategy, it allocates the same test task to the same NUMA node as much as possible to reduce cross-node access latency. In addition, the resource scheduling unit 43 is configured to fine-tune the allocation scheme according to the actual load during test task execution to achieve dynamic resource adjustment.

[0083] The execution module 40 executes test tasks within the test environment configured by the configuration module 30. For example, the execution unit 41 runs the SPEC CPU test command, generating test logs in real time during the test run. It also collects performance counter data (such as CPU cycles, instruction count, and cache miss rate) using the perf tool and system monitoring metrics (such as CPU utilization and memory usage) using a system monitoring tool. Because the execution module 40 can automatically run the complete test suite and collect multi-dimensional test data without human intervention, it saves time spent on manual test execution and provides rich data support for subsequent performance bottleneck localization.

[0084] Since each test task runs in an independent container, different test tasks will not interfere with each other. At the same time, resource limit parameters ensure that a single test task will not exhaust all the resources of the host machine, thus improving the stability of the system.

[0085] In some embodiments, the processor testing system 100 further includes an analysis module 50, see below. Figure 6 This is a schematic diagram of the structure of an analysis module provided according to some embodiments.

[0086] Analysis module 50 is configured to perform at least one of the following on test data: cleaning, transformation, and aggregation, to generate a first test report and / or a second test report. The first test report includes at least one of the following: performance score, statistical volatility, outlier detection results, and performance differences; the second test report includes at least one of the following: test environment description, configuration parameters, raw results, performance charts, comparative analysis, and conclusions and recommendations.

[0087] For example, the analysis module 50 processes the test data generated by the execution unit 41, and the data processing includes at least one of the following: (1) Cleaning data, such as identifying and removing abnormal data points caused by system interference.

[0088] (2) Transform the data, for example, convert the runtime into a performance score.

[0089] (3) Aggregate data, such as calculating the mean and standard deviation of multiple iterations.

[0090] Based on the results of the above data processing, a first test report is generated. The first test report includes at least one of the following: performance score, statistical volatility, and outlier detection results.

[0091] The analysis module 50 also generates a second test report based on the first test report. The second test report includes at least one of the following: test environment description, configuration parameters, raw results, performance charts, comparative analysis, and conclusions and recommendations.

[0092] In some embodiments, the analysis module 50 includes an analysis unit 51, a report generation unit 52, and a second database 53.

[0093] Analysis unit 51 is configured to perform at least one of the following processes on the test data: cleaning, transformation, and aggregation, to generate a first test report.

[0094] Analysis unit 51 removes outlier data points to clean the test data, converts runtime into performance scores to transform the test data, calculates the geometric mean and standard deviation to aggregate the test data, and generates a first test report that includes at least one of the following: performance score, statistical volatility, and outlier detection results.

[0095] The report generation unit 52 is connected to the analysis unit 51 and is configured to generate a second test report based on the first test report.

[0096] The report generation unit 52 receives the first test report generated by the analysis unit 51, and generates a more readable second test report based on the structured analysis data according to the report template selected by the user. It supports multiple output formats such as PDF, HTML, and Excel, and supports custom report templates, batch generation, and scheduled email reporting. Users can choose the most suitable format according to their needs.

[0097] The second database, 53, is used to store test data. For example, indexes are created based on dimensions such as platform, test version, and date to support fast queries and trend analysis.

[0098] By comparing the current test results with the historical baseline stored in the second database 53, performance degradation or improvement is automatically identified and corresponding alarm information is generated. Since the second database 53 stores historical test data, users can query the performance change trend for any time period at any time. At the same time, the automated performance degradation alarm function can promptly notify relevant personnel when performance declines, providing strong data support for continuous performance optimization.

[0099] This application also provides a processor testing method, such as Figure 7 As shown, Figure 7This is a flowchart illustrating a processor testing method according to some embodiments. The method can be applied to the processor testing system 100 described above. The processor testing method includes the following steps: Step S701: Receive a test task request, determine the initial test process based on the test task request, and initialize the test environment. The test environment is used to test the processor.

[0100] For example, the control module 10 receives test task requests through an API interface, parses the requests to determine task parameters, determines the test process, and initializes the test environment. This step, through automated request reception and parsing, enables rapid startup of test tasks.

[0101] Step S702: Obtain the processor's hardware identification information, and match the corresponding policy template in the preset policy library based on the hardware identification information. The policy template includes test configuration parameters.

[0102] For example, the identification policy module 20 logs into the target server via SSH to execute hardware detection commands to obtain information such as the CPU model. After normalization, it generates hardware identification information. Then, based on this identification information and the test type, it matches a policy template in a preset policy library to obtain configuration parameters such as the test tool version and compilation options. This step automatically identifies the hardware and matches the policy, eliminating the need for manual querying of the CPU model and selection of configurations.

[0103] After obtaining the processor's hardware identification information, the method also includes adjusting the test process based on the hardware identification information.

[0104] For example, workflow unit 12 automatically adjusts specific steps in the test process based on hardware identification information. For instance, when the platform is Zen4 architecture, a "Enable AVX-512 instruction set optimization" step is added; when the platform is Zen3 architecture, this step is skipped. This step achieves adaptive adaptation to different AMD processor platforms by automatically adjusting the test process according to the processor architecture.

[0105] Step S703: Determine the test procedure based on hardware identification information and initial test procedure.

[0106] Step S704: Configure the test environment based on the test configuration parameters.

[0107] For example, configuration module 30 automatically configures the test environment according to the test configuration parameters in the policy template: firmware configuration unit 32 sets BIOS parameters through out-of-band management interface, operating system configuration unit 33 executes OS optimization commands through SSH, and test tool deployment unit 34 pulls the corresponding image from the image repository and creates a container. This step significantly shortens the environment configuration time through full-stack automated configuration.

[0108] Step S705: Test the processor in the configured test environment based on the test procedure to obtain test data. The test data includes at least one of the following: test logs, performance counter data, and system monitoring metrics.

[0109] For example, execution module 40 runs test commands in the configured container environment, generates test logs in real time, collects performance counter data through perf, collects system monitoring metrics through system monitoring tools, and packages and stores all data after the test is completed. This step achieves full automation of test execution through automated test execution and multi-dimensional data collection.

[0110] In this embodiment, the above method steps automate the entire process from test task submission to test data acquisition through automated request reception, hardware identification, policy matching, environment configuration, and test execution. Because this method dynamically adjusts the test process and matches the corresponding policy template based on the hardware identification results, it can automatically adapt to different generations of AMD processor platforms, completing the entire test process without manual intervention, significantly improving test efficiency and eliminating discrepancies caused by human configuration.

[0111] In a specific application embodiment, taking the CPU testing of the EPYC 9004 series server as an example, the processor testing system 100 executes the following test process: Step 1: Test Task Initiation. The test control unit 11 receives the test task request, generates task parameters based on the request, and initializes the test environment. This test task request instructs the server equipped with an AMD EPYC 9654 processor to undergo SPEC CPU 2017 testing.

[0112] Step Two: Platform Identification. Identification unit 21 identifies the current platform as an AMD EPYC 9654 processor, belonging to the EPYC 9004 series, by reading the CPUID instruction and system information. Identification unit 21 uses in-band tools such as DMIDecode and LSCPU to obtain basic hardware parameter information. When basic hardware parameter information is missing, it reads FRU data via IPMI or calls the manufacturer's API to obtain supplementary hardware parameter information. The acquired information is then normalized to generate hardware identification information.

[0113] Step 3: Policy Matching. Based on the hardware identification information and the test type parameters provided by the control module 10, the policy management unit 22 confirms that the current processor is the EPYC 9004 series, and matches and selects the Zen4 policy library from the preset policy library.

[0114] Step 4: Policy Template Loading. The Zen4 policy library loads optimized configurations for EPYC 9004, including: enabling all 128 CPU cores; configuring 12-channel DDR5 memory timing optimization; setting CCD (core complex) inter-communication optimization parameters; and enabling AVX-512 instruction set optimization.

[0115] Step 5: Environment Configuration. Environment configuration unit 31 coordinates with firmware configuration unit 32, operating system configuration unit 33, and test tool deployment unit 34 to perform configuration. Firmware configuration unit 32 sets BIOS parameters via out-of-band management interface, including setting cTDP to 400W, enabling PBO2, and disabling power-saving mode; operating system configuration unit 33 connects to the target node via SSH, adjusts NUMA balancing parameters, sets CPU affinity, configures HugePages, etc.; test tool deployment unit 34 pulls the SpecCPU 2017 image optimized for Zen4 architecture from the image repository and generates a test container.

[0116] Step Six: Test Execution. Execution unit 41 runs the complete SPEC CPU2017 test suite in the configured test environment, capturing test output in real time and parsing progress information and error alarms in the logs to generate test data. Test data includes test logs, performance counter data, and system monitoring metrics. After the test task is completed, test tool deployment unit 34 cleans up the test container.

[0117] Step 7: Results Analysis. Analysis unit 51 collects the raw test data, performs cleaning, transformation, and aggregation processing, calculates the scores for each sub-test, statistically analyzes volatility, and detects outliers. Report generation unit 52 generates a standardized report based on the analysis results, including performance indicators, energy efficiency data, and a comparative analysis with a reference platform.

[0118] Through the above specific application examples, the processor testing system 100 achieves full automation from test task initiation, platform identification, strategy matching, environment configuration to test execution and result analysis, eliminating the need for manual identification of CPU models and manual configuration of the test environment, thus significantly improving testing efficiency.

[0119] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps described in the processor testing method embodiments above.

[0120] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in the processor testing method embodiments described above when running.

[0121] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0122] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in the processor testing method embodiment.

[0123] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the processor testing method embodiments.

[0124] 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.

[0125] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0126] The processor testing system and electronic device provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A processor testing system, characterized in that, include: The control module is configured to receive test task requests, determine the initial test process based on the test task requests, and initialize the test environment; The test environment is used to test the processor; The identification strategy module is configured to acquire the hardware identification information of the processor and match the strategy template corresponding to the processor in a preset strategy library based on the hardware identification information; the strategy template includes test configuration parameters. The control module is connected to the identification strategy module, and the control module is further configured to determine the test process based on the hardware identification information and the initial test process. The configuration module, connected to the identification strategy module, is configured to configure the test environment based on the test configuration parameters. The execution module is configured to test the processor in the configured test environment based on the test process and obtain test data; The test data includes at least one of the following: test logs, performance counter data, and system monitoring metrics.

2. The processor testing system according to claim 1, characterized in that, The identification strategy module includes: The identification unit is configured to acquire basic hardware parameter information of the processor and normalize the basic hardware parameter information to generate the hardware identification information. The policy management unit, connected to the identification unit, is configured to match the policy template corresponding to the processor in the preset policy library according to the hardware identification information and the test type; the policy template includes at least one of the following: test tool selection, compilation optimization options, runtime parameters, environment variables, kernel parameter tuning suggestions, and basic input / output system recommended configuration; the test type is determined based on the task parameters provided by the control module. A first database is used to store at least one of the following: the processor's microarchitecture, instruction set extensions, cache hierarchy, power consumption range, supported memory types, supported memory frequencies, known errata, compatibility list, and optimization parameter information.

3. The processor testing system according to claim 2, characterized in that, The identification unit is further configured to, in the event that the basic hardware parameter information is missing, obtain supplementary hardware parameter information based on field replaceable unit data or application programming interface; and normalize the basic hardware parameter information and the supplementary hardware parameter information to generate the hardware identification information.

4. The processor testing system according to claim 2, characterized in that, The identification unit is specifically configured to execute hardware detection commands in in-band and out-of-band modes to obtain basic hardware parameter information and / or supplementary hardware parameter information. The in-band method includes a secure enclosure protocol; the out-of-band method includes an intelligent platform management interface or a Redfish management interface.

5. The processor testing system according to claim 1, characterized in that, The control module includes: The test control unit is configured to receive the test task request, generate task parameters based on the test task request, and initialize the test environment; The workflow unit, connected to the test control unit, is configured to determine the test process based on the task parameters or user input information, and to adjust the test process based on the hardware identification information. The task scheduling unit, connected to the test control unit, is configured to generate an executable unit based on the test task request and allocate the executable unit to the corresponding test node.

6. The processor testing system according to claim 5, characterized in that, The configuration module includes: The environment configuration unit is configured to generate a configuration task list based on the test configuration parameters; The firmware configuration unit, connected to the environment configuration unit, is configured to generate basic input / output system setting parameters based on the test configuration parameters; An operating system configuration unit, connected to the environment configuration unit, is configured to generate system optimization instructions based on the policy template; the system optimization instructions are applied to adjust operating system parameters and / or configure the operating system kernel. The test tool deployment unit, connected to the environment configuration unit, is configured to select a test tool corresponding to the test configuration parameters from the image repository, and generate a test container on the test node based on the test tool for executing test tasks.

7. The processor testing system according to claim 6, characterized in that, The system optimization instructions include at least one of the following: processor scheduling policy, adjusting transparent big pages, disabling address space layout randomization, configuring memory locking limits, and modifying system limits; or... The system optimization instructions include at least one of the following: kernel module loading instructions, network protocol stack optimization instructions, and disk scheduler adjustment instructions.

8. The processor testing system according to claim 6, characterized in that, The operating system configuration unit is further configured to generate an operating system change log; the operating system change log is used to characterize the adjustments made to the operating system by the system optimization instructions.

9. The processor testing system according to claim 6, characterized in that, The firmware configuration unit is also configured to perform batch settings of the basic input / output system parameters based on the out-of-band management interface; or... The firmware configuration unit is configured to record a configuration snapshot before the basic input / output system setting parameters are set, and / or record a configuration snapshot after the basic input / output system setting parameters are set.

10. The processor testing system according to claim 6, characterized in that, The test tool deployment unit is also configured to clean up the test container after the test task is completed.

11. The processor testing system according to claim 1, characterized in that, The execution module includes: An execution unit is configured to test the processor in the configured test environment, acquire and parse the test output of the processor to generate the test data; The container management unit is configured to provide a containerized runtime environment for test tasks; The resource scheduling unit is configured to allocate core and memory nodes based on the resource utilization information of computing nodes and the test characteristics of the test task.

12. The processor testing system according to claim 11, characterized in that, The container management unit is also configured to, in the case that at least one abnormal container is included among multiple containers, restart the abnormal container, or migrate the test task running in the abnormal container to other containers among the multiple containers.

13. The processor testing system according to any one of claims 1 to 12, characterized in that, Also includes: The analysis module is configured to perform at least one of cleaning, transformation, and aggregation on the test data to generate a first test report and / or a second test report; The first test report includes at least one of the following: performance score, statistical volatility, outlier detection results, and performance differences; the second test report includes at least one of the following: test environment description, configuration parameters, raw results, performance charts, comparative analysis, and conclusions and recommendations.

14. The processor testing system according to claim 13, characterized in that, The analysis module includes: The analysis unit is configured to perform at least one of the following processes on the test data: cleaning, transformation, and aggregation, to generate a first test report; A report generation unit, connected to the analysis unit, is configured to generate a second test report based on the first test report; A second database is used to store the test data.

15. An electronic device, characterized in that, Includes the processor testing system as described in any one of claims 1-14.

Images