Interrupt function verification method and system based on binding core, terminal and storage medium

Abstract

The application relates to the technical field of servers, and specifically provides a binding-core-based interrupt function verification method and system, a terminal and a storage medium, which comprise the following steps: binding corresponding CPU cores for different test objects; making the CPU cores execute stress tests on the test objects with the binding relationship; triggering interrupt services for the test objects and recording the triggering processes; regularly collecting CPU core state information, analyzing interrupt service occurrence from the CPU core state information, and judging whether the interrupt service occurrence and the triggering process record data of the binding test objects are matched; if yes, judging that the interrupt service situation of the test objects in the stress test process is verified; the application realizes multi-machine verification through continuous unloading and loading of the kernel or multiple restarts of the system; the method verifies the interrupt processing function of the linux kernel through the binding core, and provides data support and basis for the binding CPU core when subsequent products are used in business.

Description

Technical Field

[0001] This invention belongs to the field of server technology, specifically relating to a method, system, terminal, and storage medium for interrupt function verification based on core binding. Background Technology

[0002] With the development of cloud computing and the widespread application of information technology across various fields, servers have become increasingly widely used. Linux, due to its high stability, resistance to viruses, powerful built-in command capabilities, open-source nature, high customizability, and convenient remote management, has become the mainstream operating system for servers. Different business needs require modifications to the operating system, leading to variations in Linux operating systems and their functionalities in actual use. Interrupt handling, a crucial function of the operating system, improves its efficiency and ensures concurrent operation. The proper functioning of the interrupt handling function significantly impacts the stable operation of the operating system.

[0003] In server testing, both hard drives and network cards are essential external components. Their proper functioning and performance within the server are indicators of their compatibility. Often, tests encounter situations where hard drive or network card performance fails to meet standards. The most common solution is to bind performance test commands to a specific set of CPU cores during performance testing, allowing those cores to execute the commands and verify whether the network card or hard drive's performance meets the required standards.

[0004] As mentioned above, during testing, CPU cores were bound to execute relevant instructions to check if performance met standards. However, it wasn't verified whether the instructions actually ran on the corresponding CPU after core binding, or whether hardware interrupt requests were executed on the bound CPU. Therefore, if the server has many external components, and each component is bound to a specific core to handle tasks, a problem with the kernel interrupt handling mechanism—that is, a task originally bound to CPU A running on CPU B—can lead to a single CPU core handling a large number of interrupts. When the number of interrupts exceeds the CPU core's processing capacity, the CPU core may lock up, causing anomalies in the tasks bound to it, such as I / O errors on disk I / O or packet loss in network card transmission. In severe cases, this can directly cause the server to crash, seriously affecting server operation.

[0005] Current core-binding tests only focus on whether performance meets standards, neglecting to check for interrupt handling anomalies. Specifically, they don't verify whether the task bound to CPU core A is actually running on CPU core A. This misses potential problems that might arise when interrupt handling fails. Summary of the Invention

[0006] To address the problem that existing testing methods cannot test interrupt functionality simultaneously with hard drive performance testing, this invention provides a core-binding-based interrupt functionality verification method, system, terminal, and storage medium to solve the aforementioned technical problem.

[0007] In a first aspect, the present invention provides an interrupt function verification method based on core binding, comprising:

[0008] Bind different CPU cores to different test objects;

[0009] Instruct the CPU cores to perform stress tests on test objects with binding relationships;

[0010] Trigger an interrupt service on the test object and record the triggering process;

[0011] Periodically collect CPU core status information, parse interrupt service occurrences from the CPU core status information, and determine whether the interrupt service occurrences match the trigger process record data of the bound test object:

[0012] If so, the test object's service interruption during the stress test is deemed to have passed the verification.

[0013] Furthermore, different CPU cores are bound to different test objects, including:

[0014] Disable the system hardware interrupt allocation service;

[0015] Get the total number of CPU cores on the server and group the CPU cores based on the total number of cores;

[0016] Each test object is bound to a corresponding CPU core group.

[0017] Furthermore, the CPU cores are instructed to perform stress tests on the test objects with which they are bound, including:

[0018] The CPU cores use stress testing tools to issue stress commands to the bound test objects, and each CPU core continuously performs data interaction with the bound test objects.

[0019] Furthermore, the service is interrupted on the test object, and the triggering process is recorded, including:

[0020] Randomly select a target test object, uninstall and then reload the driver of the target test object, record the information of the target test object and the driver installation and uninstallation time, and save the recorded data to the operation log. The test object can be either a hard drive or a network card.

[0021] The operating system is restarted periodically, and the binding relationship between the test object and the CPU core and the stress test execution status of the test object are restored after the system is restarted.

[0022] Furthermore, CPU core status information is collected periodically, interrupt service occurrences are analyzed from the CPU core status information, and it is determined whether the interrupt service occurrences match the trigger process record data of the bound test object, including:

[0023] The system uses performance analysis commands to periodically collect the status information of each CPU core and saves the status information to a status document named after the CPU core.

[0024] The interrupt service occurrence time and test object are parsed from the CPU core status document, and the parsed interrupt service occurrence time and test object are used as the first comparison information;

[0025] The test object information and driver loading / unloading time in the operation logs of all test objects bound to the CPU core are summarized to obtain the second comparison information;

[0026] Determine whether the first comparison information matches the second comparison information. If they match, the interrupt function is deemed to have passed the verification.

[0027] Secondly, the present invention provides an interrupt function verification system based on core binding, comprising:

[0028] Binding execution units is used to bind corresponding CPU cores to different test objects;

[0029] The stress execution unit is used to enable the CPU core to perform stress tests on test objects with binding relationships.

[0030] The service triggering unit is used to trigger a service interruption on the test object and record the triggering process;

[0031] The information acquisition unit is used to periodically collect CPU core status information, parse the interrupt service occurrence from the CPU core status information, and determine whether the interrupt service occurrence corresponds to the trigger process record data of the bound test object.

[0032] The result determination unit is used to determine that the service interruption situation of the test object during the stress test passes the verification if the service interruption situation matches the trigger process record data of the bound test object.

[0033] Furthermore, the binding execution unit includes:

[0034] The service shutdown module is used to disable the system hardware interrupt allocation service;

[0035] The grouping setting module is used to obtain the total number of CPU cores of the server and group the CPU cores based on the total number of cores;

[0036] The binding execution module is used to bind the corresponding CPU core groups to the test objects respectively.

[0037] Furthermore, the pressurization execution unit includes:

[0038] The stress execution module is used by CPU cores to issue stress commands to the bound test objects using stress testing tools, and each CPU core continuously performs data interaction on the bound test objects.

[0039] Furthermore, the service triggering unit is used for:

[0040] Randomly select a target test object, uninstall and then reload the driver of the target test object, record the information of the target test object and the driver installation and uninstallation time, and save the recorded data to the operation log. The test object can be either a hard drive or a network card.

[0041] The operating system is restarted periodically, and the binding relationship between the test object and the CPU core and the stress test execution status of the test object are restored after the system is restarted.

[0042] Furthermore, the information acquisition unit is used for:

[0043] The system uses performance analysis commands to periodically collect the status information of each CPU core and saves the status information to a status document named after the CPU core.

[0044] The interrupt service occurrence time and test object are parsed from the CPU core status document, and the parsed interrupt service occurrence time and test object are used as the first comparison information;

[0045] The test object information and driver loading / unloading time in the operation logs of all test objects bound to the CPU core are summarized to obtain the second comparison information;

[0046] Determine whether the first comparison information matches the second comparison information. If they match, the interrupt function is deemed to have passed the verification.

[0047] Thirdly, a terminal is provided, including:

[0048] Processor, memory, among which,

[0049] This memory is used to store computer programs.

[0050] The processor is used to retrieve and run the computer program from memory, causing the terminal to perform the terminal method described above.

[0051] Fourthly, a computer storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the methods described in the above aspects.

[0052] The beneficial effects of this invention are that the interrupt function verification method, system, terminal and storage medium based on core binding provided by this invention verify whether the Linux kernel interrupt is executed on the corresponding CPU during core binding test, and verify whether the Linux kernel interrupt handling function is normal; this invention achieves multi-machine verification by continuously unloading and loading the kernel or restarting the system multiple times; this method verifies the Linux kernel interrupt handling function by binding the kernel, and provides data support and basis for subsequent products to bind CPU cores when running business.

[0053] Furthermore, the design principle of this invention is reliable, the structure is simple, and it has a very wide range of application prospects. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.

[0056] Figure 2 This is a schematic block diagram of a system according to an embodiment of the present invention.

[0057] Figure 3 This is a schematic diagram of the structure of a terminal provided in an embodiment of the present invention. Detailed Implementation

[0058] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0059] The key terms used in this invention will be explained below.

[0060] The CPU (Central Processing Unit) is the core of a computer system for computation and control, and is the final execution unit for information processing and program execution.

[0061] Figure 1 This is a schematic flowchart illustrating a method according to an embodiment of the present invention. Wherein, Figure 1 The executing entity can be a core-bound interrupt function verification system.

[0062] like Figure 1 As shown, the method includes:

[0063] Step 110: Bind the corresponding CPU core to each different test object;

[0064] Step 120: Instruct the CPU core to perform a stress test on the test object with the binding relationship;

[0065] Step 130: Trigger an interrupt service for the test object and record the triggering process;

[0066] Step 140: Periodically collect CPU core status information, parse the interrupt service occurrence information from the CPU core status information, and determine whether the interrupt service occurrence information matches the trigger process record data of the bound test object:

[0067] Step 150: If yes, then the interruption of service of the test object during the stress test is deemed to have passed the verification.

[0068] To facilitate understanding of the present invention, the following description further illustrates the interrupt function verification method based on core binding, using the principle of the interrupt function verification method based on core binding in the present invention and the process of verifying the interrupt function based on core binding in the embodiments.

[0069] Specifically, the test object can be a hard drive or a network card, and the core-bound interrupt function verification method includes the following:

[0070] The total number of CPU cores on the server can be obtained by checking the ` / proc / cpuinfo` file in Linux; performance or stress commands can be issued to external hard drives or network cards using `fio` or `netperf` to generate a large amount of data transmission or reception, ensuring that they can send a large number of interrupt requests to the CPU; the `taskset` command in Linux can be used to bind commands to specific CPU cores; the `top` command can be used to obtain the running status data of each CPU core to determine whether the command is running on the bound CPU; the `modprobe -r driver` and `modprobedriver` commands can be used to continuously unload and load the drivers of hard drives or network cards to simulate continuous plugging and unplugging of devices; and the OS can be restarted using commands such as `reboot`, `ipmitool power cycle`, etc.

[0071] The following explanation uses a hard drive as an example. The specific testing process is as follows:

[0072] (1) Set up a server with NVMe hard disk configuration and install the OS system specified by the business side;

[0073] (2) Disable the system irqbalance service (hardware interrupt allocation service) to facilitate the binding and execution of subsequent stress commands:

[0074] systemctl stop irqbalance.service

[0075] systemctl disable irqbalance.service

[0076] And confirm that the service is closed using the following command:

[0077] systemctl status irqbalance.servic

[0078] (3) Ensure that the OS system has the fio hard disk stress testing tool installed so that stress commands can be issued to the hard disk, so that the hard disk can send and receive a large amount of data and ensure that the hard disk can send a large number of interrupt requests to the CPU.

[0079] You can execute the command -v fio to see if there is any return information. If there is no return information, it means that the tool has not been installed.

[0080] (4) Use `cat / proc / cpuinfo|grep processor|wc -l` to get the total number of CPU cores on the server (counting starts from 0);

[0081] (5) Group the total number of CPU cores obtained in step 3 into groups of 4;

[0082] (6) Send 4kb-4job-64QD random reads to the hard disk (in this IO read / write mode, IOps are relatively high, IO concurrency is relatively large, and it is easy to meet the requirement of a large number of interrupt requests to the CPU), and bind the CPU, with the CPU core being the group generated in step four;

[0083] nohup taskset-c 0-3fio--time_based=1--rw=randread--name=preheat--numjobs=4--direct=1--group_reporting=1--bs=4K--ioengine=libaio--runti me=300--iodepth=64--filename= / dev / nvme0n1--output=fio_output.log--cpus_allowed=0-3--cpus_allowed_policy=split> / dev / null 2>&1

[0084] (7) After step 6 is executed, use the linux top command to get the status of each CPU core, collect data every 5 seconds, and store the data in a document. The document is named after the bound CPU core for easy viewing later.

[0085] By default, top does not display the status of each CPU core, but only displays overall CPU information. Furthermore, the screen printouts from top cannot be output to a document.

[0086] The following settings are required at this point:

[0087] First, run top. After entering the top's regular interface, press the number 1 key. This will display the information of each CPU core. However, this method only works once, and the information cannot be saved. You can only take a screenshot, which is inconvenient for subsequent result judgment.

[0088] After entering the mode that displays information about each CPU core, press Shift+W to save the top settings. Then, exit and run top again to directly display information about each CPU core.

[0089] To facilitate subsequent result evaluation, the command `top -bn1|grep "%Cpu*"` is executed every 5 seconds, and the results are redirected to a file named after the bound CPU core.

[0090] (8) After traversing the CPU group in step 5, execute modprobe -r nvme to uninstall the nvme driver. At this time, the nvme hard drive cannot be recognized by the system. Then execute modprobe nvme to load the nvme driver. After the hard drive is recognized, execute steps 4, 5, 6, and 7 again, repeating 5 times.

[0091] (9) After step 8 is completed, execute reboot or ipmitool power cycle to issue a restart command to the OS and allow the system to restart and boot. After entering the system, repeat the above steps multiple times to ensure the validity of the verification results.

[0092] (10) Judgment of the final result:

[0093] If, upon reviewing the statistics documentation, the CPU core experiencing the hard interrupt is a bound CPU core, and other CPU cores do not exhibit abnormal hard interrupts, it indicates that the operating system's interrupt handling is functioning correctly. Otherwise, it suggests an anomaly in the operating system's interrupt handling, requiring inspection of the relevant interrupt handling code by OS personnel. Only when interrupt handling is functioning correctly can stress test results truly reflect hard drive performance.

[0094] like Figure 2 As shown, the system 200 includes:

[0095] The execution unit 210 is used to bind the corresponding CPU core to different test objects respectively;

[0096] The stress execution unit 220 is used to enable the CPU core to perform stress tests on test objects with binding relationships;

[0097] Service triggering unit 230 is used to trigger an interruption service to the test object and record the triggering process;

[0098] The information acquisition unit 240 is used to periodically collect CPU core status information, parse the interrupt service occurrence status from the CPU core status information, and determine whether the interrupt service occurrence status corresponds to the trigger process record data of the bound test object.

[0099] The result determination unit 250 is used to determine that the interruption service situation of the test object during the stress test passes the verification if the interruption service situation matches the trigger process record data of the bound test object.

[0100] Optionally, as an embodiment of the present invention, the binding execution unit includes:

[0101] The service shutdown module is used to disable the system hardware interrupt allocation service;

[0102] The grouping setting module is used to obtain the total number of CPU cores of the server and group the CPU cores based on the total number of cores;

[0103] The binding execution module is used to bind the corresponding CPU core groups to the test objects respectively.

[0104] Optionally, as an embodiment of the present invention, the pressurization execution unit includes:

[0105] The stress execution module is used by CPU cores to issue stress commands to the bound test objects using stress testing tools, and each CPU core continuously performs data interaction on the bound test objects.

[0106] Optionally, as an embodiment of the present invention, the service triggering unit is used for:

[0107] Randomly select a target test object, uninstall and then reload the driver of the target test object, record the information of the target test object and the driver installation and uninstallation time, and save the recorded data to the operation log. The test object can be either a hard drive or a network card.

[0108] The operating system is restarted periodically, and the binding relationship between the test object and the CPU core and the stress test execution status of the test object are restored after the system is restarted.

[0109] Optionally, as an embodiment of the present invention, the information acquisition unit is used for:

[0110] The system uses performance analysis commands to periodically collect the status information of each CPU core and saves the status information to a status document named after the CPU core.

[0111] The interrupt service occurrence time and test object are parsed from the CPU core status document, and the parsed interrupt service occurrence time and test object are used as the first comparison information;

[0112] The test object information and driver loading / unloading time in the operation logs of all test objects bound to the CPU core are summarized to obtain the second comparison information;

[0113] Determine whether the first comparison information matches the second comparison information. If they match, the interrupt function is deemed to have passed the verification.

[0114] Figure 3 This is a schematic diagram of the structure of a terminal 300 provided in an embodiment of the present invention. The terminal 300 can be used to execute the interrupt function verification method based on core binding provided in an embodiment of the present invention.

[0115] The terminal 300 may include a processor 310, a memory 320, and a communication unit 330. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation of the present invention. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0116] The memory 320 can be used to store the execution instructions of the processor 310. The memory 320 can be implemented by any type of volatile or non-volatile memory terminal or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the terminal 300 is able to perform some or all of the steps in the above method embodiments.

[0117] The processor 310 serves as the control center of the storage terminal, connecting various parts of the electronic terminal via various interfaces and lines. It executes software programs and / or modules stored in the memory 320, and calls data stored in the memory to perform various functions of the electronic terminal and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 310 may consist only of a central processing unit (CPU). In this embodiment of the invention, the CPU may have a single processing core or include multiple processing cores.

[0118] The communication unit 330 is used to establish a communication channel, enabling the storage terminal to communicate with other terminals. It can receive user data sent by other terminals or send user data to other terminals.

[0119] The present invention also provides a computer storage medium, wherein the computer storage medium may store a program, which, when executed, may include some or all of the steps provided in the embodiments of the present invention. The storage medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0120] Therefore, this invention verifies whether the Linux kernel interrupt is executed on the corresponding CPU during the core binding test and verifies whether the Linux kernel interrupt handling function is normal. This invention achieves multi-machine verification by continuously unloading and loading the kernel or restarting the system multiple times. This method verifies the Linux kernel interrupt handling function by binding the core, and provides data support and basis for binding CPU cores when the subsequent product is running business. The technical effects that this embodiment can achieve can be seen in the description above, and will not be repeated here.

[0121] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other medium capable of storing program code. It includes several instructions to cause a computer terminal (which may be a personal computer, a server, or a second terminal, a network terminal, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0122] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the terminal embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0123] In the embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0124] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0125] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0126] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the invention should also be covered within the protection scope of the invention. Therefore, the protection scope of the invention should be determined by the scope of the claims.

Claims

1. A method for verifying interrupt functions based on core binding, characterized in that, include: Set up servers with different test object configurations and install the OS system specified by the business side; The test object is a hard drive or a network card; Bind different CPU cores to different test objects; The CPU cores are instructed to perform stress tests on the test objects with which they are bound. This includes: the CPU cores using the fio or netperf stress testing tools to issue stress test commands to the bound test objects, and each CPU core continuously performing data interaction on the bound test objects; wherein, the Linux system taskset command is used to bind the commands to the corresponding CPU cores for execution. Trigger an interrupt service for the test object and record the triggering process; trigger an interrupt service for the test object and record the triggering process, including: randomly selecting a target test object and uninstalling and then reloading the driver of the target test object, recording the information of the target test object and the driver installation and uninstallation time, and saving the recorded data to the operation log; periodically restart the operating system, and restore the binding relationship between the test object and the CPU core and the stress test execution status of the test object after restarting the system; Periodically collect CPU core status information, parse interrupt service occurrences from the CPU core status information, and determine whether the interrupt service occurrences match the trigger process record data of the bound test object: If so, the test object's service interruption during the stress test is deemed to have passed the verification.

2. The method according to claim 1, characterized in that, Bind different CPU cores to different test objects, including: Disable the system hardware interrupt allocation service; Get the total number of CPU cores on the server and group the CPU cores based on the total number of cores; Each test object is bound to a corresponding CPU core group.

3. An interrupt function verification system based on core binding, characterized in that, include: Binding execution units is used to bind corresponding CPU cores to different test objects; The test object is a hard drive or a network card; The stress execution unit is used to enable the CPU core to perform stress tests on test objects with binding relationships. The service triggering unit is used to trigger a service interruption on the test object and record the triggering process; Trigger an interrupt service for the test object and record the triggering process, including: randomly selecting a target test object and uninstalling and then reloading the driver of the target test object, recording the information of the target test object and the driver installation and uninstallation time, and saving the recorded data to the operation log; periodically restarting the operating system, and restoring the binding relationship between the test object and the CPU core and the stress test execution status of the test object after the system restart; The information acquisition unit is used to periodically collect CPU core status information, parse the interrupt service occurrence from the CPU core status information, and determine whether the interrupt service occurrence matches the trigger process record data of the bound test object. The result determination unit is used to determine that the service interruption situation of the test object during the stress test passes the verification if the service interruption situation matches the trigger process record data of the bound test object. The system also performs the following: setting up servers with different test object configurations and installing the OS system specified by the business side; The pressurization execution unit includes: The stress execution module is used by CPU cores to issue stress test commands to the bound test objects using the fio or netperf stress testing tools. Each CPU core continuously performs data interaction on the bound test objects. The Linux system taskset command is used to bind the commands to the corresponding CPU cores for execution.

4. The system according to claim 3, characterized in that, The binding execution unit includes: The service shutdown module is used to disable the system hardware interrupt allocation service; The grouping setting module is used to obtain the total number of CPU cores of the server and group the CPU cores based on the total number of cores; The binding execution module is used to bind the corresponding CPU core groups to the test objects respectively.

5. A terminal, characterized in that, include: processor; Memory used to store the processor's execution instructions; The processor is configured to perform the method according to any one of claims 1-2.

6. A computer-readable storage medium storing a computer program, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-2.

Images