Simulator process monitoring method, system, terminal and medium

Abstract

This invention relates to the field of emulator monitoring, specifically disclosing an emulator process monitoring method, system, terminal, and medium. It involves a one-to-one binding between service cores and processes, and a one-to-many binding between fixed cores and processes. When a new process is added, a static recycling method using a recycling pool is executed. This includes binding the new process to an idle service core if one is available; otherwise, unbinding processes with CPU utilization below a threshold from their bound service cores, releasing the service cores, and then binding the new process to an idle service core. When no new processes are added, a dynamic recycling method using a recycling pool is executed. This includes restoring processes with CPU utilization greater than or equal to a threshold on fixed cores to idle service cores, and binding processes with CPU utilization below a threshold on service cores to fixed cores. This invention binds processes with low CPU utilization to fixed cores, enabling a one-to-many binding between fixed cores and processes, increasing the number of processes running simultaneously and improving CPU resource utilization.

Description

Technical Field

[0001] This invention relates to the field of simulator monitoring, specifically to a method, system, terminal, and medium for simulator process monitoring. Background Technology

[0002] In the early stages of chip design, before the chip has been fabricated, simulations are used to verify the chip's functionality from multiple dimensions. One such method is using the QEMU simulator (hereinafter referred to as the simulator) to verify the chip design.

[0003] As an executable file, the emulator runs as a process when the operating system retrieves it. The emulator process is subject to normal scheduling by the operating system and must adhere to its scheduling rules. When other processes running on the operating system have high CPU usage, the CPU usage of the corresponding emulator process will decrease, which compromises the stability of the emulator process's operation. Therefore, the emulator process's CPU usage is limited by the operating system's scheduling rules and the performance of other processes. If a batch of emulator processes are launched and there are no available CPU resources, the emulator's performance will degrade.

[0004] To provide a stable and usable simulator testing environment whose performance is unaffected by the operating system, server CPU cores are typically isolated, and simulator processes are bound to these isolated CPU cores. However, when server resources are limited, and each server offers a limited number of CPU cores available for isolation and binding, pulling simulator processes presents the following problems: 1) When simulator processes are bound one-to-one to CPU cores, the maximum number of simulator processes running simultaneously is limited by the number of isolated CPU cores; 2) If the binding relationship between simulator processes and CPU cores remains unchanged, and users only perform a few operations on the simulator, the simulator process's CPU utilization is low, resulting in wasted CPU resources. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides a method, system, terminal, and medium for monitoring emulator processes. This method binds emulator processes with low CPU utilization to a fixed core, enabling a one-to-many binding between the fixed core and emulator processes. This increases the number of emulator processes running simultaneously and improves CPU resource utilization.

[0006] In a first aspect, the technical solution of the present invention provides a method for monitoring simulator processes, comprising the following steps:

[0007] (1) The steps for dividing the isolated CPU cores;

[0008] The isolated CPU is divided into business cores and fixed cores, and all fixed cores form a recycling pool; the business cores are bound one-to-one with the simulator processes, and the fixed cores are bound one-to-many with the simulator processes.

[0009] (2) Steps for adding a new emulator process bound to a core;

[0010] When a new emulator process is added, if there are idle service cores, the new emulator process is bound to one of the idle service cores. If there are no idle service cores, a target service core is selected, the emulator process on the target service core is transferred to a fixed core, and the new emulator process is bound to one of the target service cores. If there are no target service cores, the binding of the new emulator process is terminated. Here, the target service core refers to the service core to which the emulator process bound has a CPU utilization rate less than the utilization rate threshold.

[0011] (3) Steps for transferring the emulator process to the bound core;

[0012] When no new simulator processes are added, the simulator processes on the target business core are periodically transferred and bound to a fixed core, and the simulator processes on the target fixed core are transferred and bound to an idle business core. The target fixed core refers to a fixed core whose CPU utilization rate of the simulator process bound to it is greater than or equal to the utilization rate threshold.

[0013] In an optional implementation, if an idle service core exists, the newly added emulator process is bound to one of the idle service cores; if no idle service core exists, a target service core is selected, the emulator process on the target service core is transferred to a fixed core, and then the newly added emulator process is bound to one of the target service cores. Specifically, this includes:

[0014] Get the process ID of the newly added emulator process and save it to the list of newly added emulator processes;

[0015] Obtain the status of each service core and count the number of idle service cores;

[0016] Determine if the number of idle service cores is greater than or equal to 1;

[0017] If so, the newly added simulator process will be bound to one of the idle business cores, and the status of the bound business core will be recorded as occupied. At the same time, the newly added simulator process will be deleted from the list of newly added simulator processes.

[0018] If not, then filter the target business cores, transfer the simulator process on the target business core to a fixed core, and then bind the newly added simulator process to one of the target business cores.

[0019] In one optional implementation, target service cores are selected, the simulator process on the target service core is transferred to a fixed core, and then the newly added simulator process is bound to one of the target service cores. If no target service core exists, the binding of the newly added simulator process is exited. Specifically, this includes:

[0020] Step 1: Obtain information on all emulator processes and filter out the process ID and CPU usage of all currently running emulator processes;

[0021] Step 2: Save the filtered emulator process information to the first file;

[0022] Step 3: Check if there is a next emulator process information in the first file. If there is, proceed to step 4; otherwise, proceed to step 8.

[0023] Step 4: Determine if the CPU utilization of the next emulator process is less than the utilization threshold. If yes, proceed to step 5; otherwise, return to step 3.

[0024] Step 5: Determine whether the CPU core bound to the next emulator process is a business core. If so, proceed to step 6; otherwise, return to step 3.

[0025] Step 6: Recycle the next emulator process into the recycling pool;

[0026] Step 7: Determine whether the recycling pool has successfully recycled. If so, return to step 2; otherwise, exit abnormally and remove the newly added emulator process from the list of newly added emulator processes.

[0027] Step 8: Count the number of idle service cores;

[0028] Step 9: Determine if the number of idle service cores is greater than or equal to 1. If so, bind the newly added emulator process to one of the idle service cores and record the status of the bound service core as occupied. At the same time, delete the newly added emulator process from the list of newly added emulator processes. Otherwise, exit abnormally and delete the newly added emulator process from the list of newly added emulator processes.

[0029] In an optional implementation, the method further includes the step of constructing a process ID mapping table, specifically including:

[0030] Construct a data structure to record the process ID information of the emulator processes bound to each fixed core, and build a process ID mapping table;

[0031] After the terminal where the emulator process is located restarts, the data in the recycling pool is initialized, and all process IDs in the process ID mapping table are cleared to zero.

[0032] In an optional implementation, when no new simulator processes are added, the simulator processes on the target service core are periodically transferred and bound to a fixed core, and the simulator processes on the target fixed core are periodically transferred and bound to an idle service core. Specifically, this includes:

[0033] Step 1: Obtain the list of newly added emulator processes;

[0034] Step 2: Determine if the list of newly added emulator processes is empty. If not, wait for a preset time and return to Step 1. If yes, obtain the process ID information that is not 0 from the process ID mapping table and record it in the second file.

[0035] Step 3: Determine if there is a next process ID in the second file. If not, wait for a preset time and return to Step 1. If yes, proceed to Step 4.

[0036] Step 4: Query the CPU usage of the emulator process in the next process ID information, and determine whether the CPU usage is greater than or equal to the usage threshold. If not, return to step 3; otherwise, proceed to step 5.

[0037] Step 5: Query the fixed core information bound to the emulator process of the next process ID information;

[0038] Step 6: Obtain the number of idle service cores;

[0039] Step 7: Determine if the number of idle service cores is greater than or equal to 1. If yes, proceed to step 8; otherwise, proceed to step 10.

[0040] Step 8: Release the simulator process with the next process ID from the recycling pool;

[0041] Step 9: Determine whether the release from the recycling pool was successful. If so, return to step 3; otherwise, wait for the preset time and then return to step 1.

[0042] Step 10: Obtain information on all emulator processes and filter out the process ID and CPU usage of all currently running emulator processes.

[0043] Step 11: Save the filtered emulator process information to a third file;

[0044] Step 12: Check if there is a next emulator process information in the third file. If there is, proceed to step 13; otherwise, proceed to step 17.

[0045] Step 13: Determine if the CPU utilization of the next emulator process is less than the utilization threshold. If so, execute only step 14; otherwise, return to step 12.

[0046] Step 14: Determine whether the CPU core bound to the next emulator process is a business core. If so, proceed to step 15; otherwise, return to step 12.

[0047] Step 15: Recycle the next emulator process into the recycling pool;

[0048] Step 16: Determine whether the recycling pool has successfully recycled. If so, return to step 12; otherwise, exit abnormally and proceed to step 17.

[0049] Step 17: Count the number of idle service cores;

[0050] Step 18: Determine if the number of idle service cores is greater than or equal to 1. If so, proceed to step 8; otherwise, wait for a preset time and return to step 1.

[0051] In an optional implementation, the emulator process is recycled to a recycling pool, specifically including:

[0052] Step 1: Obtain the emulator process information that needs to be recycled, and set the recycling flag to 0;

[0053] Step 2: Loop through the process ID mapping table to find the first element with process ID 0, mark it as the target element, and proceed to Step 3; if no element with process ID 0 is found, no setting is performed.

[0054] Step 3: Bind the simulator process to be recycled to the fixed core corresponding to the target element, unbind the simulator process to be recycled from the business core, record the business core status as idle, fill the process number of the simulator process to be recycled into the target element, set the recycling flag to 1, and exit the loop.

[0055] Step 4: Check the recycling flag. If the recycling flag is 1, record that the recycling was successful; if the recycling flag is 0, record that the recycling failed.

[0056] In an optional implementation, releasing the emulator process from the recycling pool specifically includes:

[0057] Step 1: Obtain the emulator process information and idle service core number that need to be released, and set the release flag to 0;

[0058] Step 2: Loop through the process ID mapping table to find the element corresponding to the process ID of the emulator process to be released, record it as the target element, and then execute Step 3; if no element corresponding to the process ID of the emulator process to be released is found, no settings are made.

[0059] Step 3: Bind the simulator process to be released to the idle business core and record the business core status as occupied. At the same time, unbind the simulator process to be released from the fixed core, clear the target element, set the release flag to 1, and exit the loop.

[0060] Step 4: Check the release flag. If the release flag is 1, record that the release was successful; if the release flag is 0, record that the release failed.

[0061] Secondly, the technical solution of the present invention provides an emulator process monitoring system, including,

[0062] CPU core partitioning module: This module partitions isolated CPU cores into business cores and fixed cores, with all fixed cores forming a recycling pool. Business cores are bound one-to-one to simulator processes, while fixed cores are bound one-to-many to simulator processes.

[0063] The module adds a core binding feature for new emulator processes. This involves binding new emulator processes to specific cores. If an idle business core exists, the new emulator process is bound to it. If no idle business core exists, a target business core is selected, and the emulator process on that target core is transferred to a fixed core. The new emulator process is then bound to one of the target business cores. If no target business core exists, the binding process is terminated. The target business core refers to the business core to which the bound emulator process has a CPU utilization rate below a certain threshold.

[0064] Emulator process transfer and core binding module: Performs emulator process transfer and core binding, including periodically transferring and binding the emulator process on the target business core to a fixed core when no new emulator processes are added, and transferring and binding the emulator process on the target fixed core to an idle business core; where the target fixed core refers to a fixed core whose CPU utilization of the emulator process bound to it is greater than or equal to the utilization threshold.

[0065] Thirdly, the technical solution of the present invention provides a terminal, comprising:

[0066] Memory, used to store the emulator process monitoring program;

[0067] A processor, configured to implement the steps of the simulator process monitoring method as described above when executing the simulator process monitoring program.

[0068] Fourthly, the present invention provides a computer-readable storage medium storing an emulator process monitoring program, which, when executed by a processor, implements the steps of the emulator process monitoring method described in any of the above claims.

[0069] The present invention provides a method, system, terminal, and medium for monitoring simulator processes, which has the following advantages over the prior art: First, the isolated CPU core is divided into service cores and fixed cores. Based on this, simulator processes with low CPU utilization are bound to fixed cores, enabling a one-to-many binding between fixed cores and simulator processes. This allows for flexible and dynamic adjustment of resource allocation according to the needs of simulator processes. When service core resources are scarce, low-load simulator processes can be efficiently migrated to fixed cores, thereby freeing up service core resources to accommodate new processes, increasing the number of simulator processes running simultaneously, and significantly improving the overall utilization of CPU resources. Attached Figure Description

[0070] To more clearly illustrate the technical solutions of 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, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0071] Figure 1 This is a schematic diagram of a simulator process monitoring method provided in an embodiment of the present invention.

[0072] Figure 2 This is a diagram illustrating process binding to CPU cores on a server.

[0073] Figure 3 This is a diagram illustrating the partitioning of a server's CPU cores.

[0074] Figure 4 This is a schematic diagram of the business core state transition.

[0075] Figure 5 This is a diagram illustrating the process of adding a new emulator process and binding it to a core.

[0076] Figure 6 This is a schematic diagram of the emulator process transfer and core binding process.

[0077] Figure 7 This is a flowchart illustrating the process of recycling emulator processes into the recycling pool.

[0078] Figure 8 This is a flowchart illustrating the process of releasing the emulator process from the recycling pool.

[0079] Figure 9 This is a schematic block diagram of an simulator process monitoring system provided in an embodiment of the present invention.

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

[0081] To enable those skilled in the art to better understand the present invention, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0082] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

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

[0084] QEMU is short for "Quick EMUlator," which is an open-source, cross-platform, system emulator and simulator.

[0085] Emulator: A hardware device that is purely software-based and simulated using QEMU. It is an executable file that runs on an x86 Linux or Windows operating system.

[0086] Core binding: In Linux, "core binding" refers to binding a specific process or thread to a specific CPU core to run in order to control and optimize system performance, resource allocation, and load balancing.

[0087] Unbinding: "Unbinding" refers to removing a process or thread that is bound to a specific CPU core from its execution.

[0088] CPU utilization is a measure of the amount of time the CPU spends executing various tasks and processes on a computer.

[0089] CPU resources: CPU resources include processing speed, number of cores, etc., which determine the computer's processing power and multitasking capabilities.

[0090] CPU cores: the number of CPU cores.

[0091] Figure 1 This is a schematic flowchart of an emulator process monitoring method provided in an embodiment of the present invention. Figure 1 The executing entity can be an emulator process monitoring system. The emulator process monitoring method provided in this embodiment of the invention is executed by a computer device; correspondingly, the emulator process monitoring system runs on the computer device. Depending on different requirements, the order of the steps in this flowchart can be changed, and some steps can be omitted.

[0092] like Figure 1 As shown, the method includes the following steps.

[0093] S1, the step of dividing the isolated CPU cores;

[0094] The isolated CPU is divided into service cores and fixed cores, and all fixed cores form a recycling pool; the service cores are bound one-to-one with the simulator processes, and the fixed cores are bound one-to-many with the simulator processes.

[0095] S2, adding steps for binding emulator processes to cores;

[0096] When a new emulator process is added, if there is an idle service core, the new emulator process is bound to one of the idle service cores. If there is no idle service core, a target service core is selected, the emulator process on the target service core is transferred to a fixed core, and the new emulator process is bound to one of the target service cores. If there is no target service core, the binding of the new emulator process is terminated. The target service core refers to the service core to which the emulator process is bound has a CPU utilization rate less than the utilization rate threshold.

[0097] S3, the steps for transferring and binding emulator processes to cores;

[0098] When no new simulator processes are added, the simulator processes on the target business core are periodically transferred and bound to a fixed core, and the simulator processes on the target fixed core are transferred and bound to an idle business core. The target fixed core refers to a fixed core whose CPU utilization rate of the simulator process bound to it is greater than or equal to the utilization rate threshold.

[0099] In real-world scenarios, the CPU utilization of each emulator process varies depending on the user's actual usage. For example, when debugging with the emulator, the time interval between commands sent to the emulator is long, resulting in low CPU utilization. Conversely, when testing with the emulator, the time interval between commands sent to the emulator is short, resulting in high CPU utilization. This embodiment considers the different CPU utilization rates of different emulator processes. Given limited server resources, isolated CPU cores are divided into service cores and fixed cores. Emulator processes with lower CPU utilization are bound to fixed cores, allowing one fixed core to be bound to multiple emulator processes. Emulator processes with higher CPU utilization are bound to service cores. This ensures that more emulator processes can run while maintaining emulator performance, thereby improving CPU resource utilization.

[0100] To further understand the present invention, the above steps will be described in detail below.

[0101] The first part involves dividing the isolated CPU cores.

[0102] Figure 2 This diagram illustrates the process binding to CPU cores on a server. The CPU cores on the server are isolated, with a portion of these cores used for binding to emulator processes. The unisolated CPU cores are used for normal operating system scheduling and binding to server and operating system processes. The isolated CPU cores are divided into business cores and fixed cores, with all fixed cores forming a recycling pool. Business cores are bound one-to-one to emulator processes, while fixed cores are bound one-to-many to emulator processes.

[0103] Figure 3 This is a diagram illustrating server CPU core partitioning. Modify the `isolcpus` parameter to isolate server CPU cores. For example, `isolcpus=8-31,41-63`. Save the settings and restart the operating system. The isolated CPU cores are then further partitioned: service cores are 10~31, 42~63. Fixed cores 8, 9, 41, and 42 are grouped into a recycling pool.

[0104] Each simulator process is bound to a business core one-to-one, so a maximum of 44 simulator processes can be bound simultaneously. With a CPU utilization rate of less than 10% as the threshold, a fixed core in the recycling pool can reclaim a maximum of 10 simulator processes simultaneously, meaning the recycling pool can reclaim a maximum of 40 simulator processes at a time.

[0105] In this embodiment, the service core status is divided into three states: idle, occupied, and pending release. Transitions between these three states are possible: idle can transition to occupied, occupied can transition to pending release, and pending release can transition to idle. Figure 4 This is a diagram illustrating the state transition of the business core. The idle state is the state where there is no bound emulator process, the occupied state is the state where there is a bound emulator process, and the state to be released is the state where the CPU utilization of the emulator process is less than 10%, and the emulator process is to be transferred to a fixed core.

[0106] The business core status values ​​are divided into 0, 1, and 2, as shown in Table 1.

[0107] Table 1: Business Core Status

[0108]

[0109] After the server restarts, the status of all service cores is set to 0, i.e., idle, and recorded in a file, as shown in Table 2.

[0110] Table 2: Business Core Status Set to 0

[0111]

[0112] When a new emulator process is added, a static recycling method is executed. This involves binding the new emulator process to an idle business core if one is available. If no business core is available, emulator processes with CPU utilization below the utilization threshold are unbound from their bound business cores, releasing the business cores, and then the new emulator process is bound to an idle business core. When no new emulator processes are added, a dynamic recycling method is executed. This involves restoring emulator processes on fixed cores with CPU utilization greater than or equal to the utilization threshold to idle business cores, and binding emulator processes on business cores with CPU utilization below the utilization threshold to fixed cores. In this embodiment, the utilization threshold is set to 10%.

[0113] This embodiment creates a list of newly added emulator processes, initialized to 0. When a new emulator process is added, it is saved to this list. When a newly added emulator process completes its startup or exits abnormally, it is removed from the list of newly added emulator processes.

[0114] Part Two: Adding a core binding to the emulator process.

[0115] In this embodiment, when binding a new emulator process to a core, a static recycling method using a recycling pool is employed: If there is an idle service core, the emulator process is bound to the service core, and the service core status is recorded as occupied. If there is no idle service core, the CPU utilization of the emulator processes is queried in a loop. Emulator processes with CPU utilization less than 10% that are bound to service cores are bound to fixed cores in the recycling pool, and the service core is released. After one loop, another check is performed. If there is an idle service core, the emulator process is bound to the service core, and the service core status is recorded as occupied. If there is no idle service core, the process exits abnormally. Figure 5 This is a diagram illustrating the process of adding a new emulator process and binding it to a core, which includes the following steps.

[0116] Step 1: Obtain the process ID of the newly added emulator process and save it to the list of newly added emulator processes.

[0117] Step 2: Obtain the status of each business core and count the number of idle business cores.

[0118] Step 3: Determine if the number of idle service cores is greater than or equal to 1.

[0119] Step 4: If yes, bind the newly added simulator process to one of the idle service cores, record the status of the bound service core as occupied, and delete the newly added simulator process from the list of newly added simulator processes.

[0120] Step 5: If not, then filter the target business cores, transfer the simulator process on the target business core to a fixed core, and then bind the newly added simulator process to one of the target business cores.

[0121] Step 5.1: Obtain information on all emulator processes and filter out the process ID and CPU usage of all currently running emulator processes.

[0122] An optional implementation uses the `top` command to obtain process information. The `top` command takes a value at a specific moment, assuming that the CPU usage of the emulator processes remains constant over a period of time.

[0123] Step 5.2: Save the filtered emulator process information to the first file.

[0124] Step 5.3: Check if there is a next emulator process information in the first file. If there is, proceed to step 5.4; otherwise, proceed to step 5.8.

[0125] Step 5.4: Determine if the CPU utilization of the next emulator process is less than the utilization threshold. If yes, proceed to step 5.5; otherwise, return to step 5.3.

[0126] Step 5.5: Determine whether the CPU core bound to the next emulator process is a business core. If so, proceed to step 5.6; otherwise, return to step 5.3.

[0127] Step 5.6: Recycle the next emulator process into the recycling pool (the process recycling process will be explained in detail later).

[0128] Step 5.7: Determine whether the recycling pool has successfully recycled. If so, return to step 5.2; otherwise, exit abnormally and remove the newly added emulator process from the list of newly added emulator processes.

[0129] Step 5.8: Count the number of idle service cores.

[0130] Step 5.9: Determine if the number of idle service cores is greater than or equal to 1. If so, bind the newly added emulator process to one of the idle service cores and record the status of the bound service core as occupied. At the same time, delete the newly added emulator process from the list of newly added emulator processes. Otherwise, exit abnormally and delete the newly added emulator process from the list of newly added emulator processes.

[0131] In one specific embodiment, if the next emulator process information exists in the first file, it is determined whether the CPU utilization of the next emulator process is less than 10%. If it is greater than or equal to 10%, the first file is queried again to see if the next emulator process information exists. If it is less than 10%, it is determined whether the bound core number is a business core. If it is not a business core, the first file is queried again to see if the next emulator process information exists. If it is a business core, the next emulator process is recycled to the recycling pool.

[0132] Part Three: Emulator Process Transfer and Core Binding.

[0133] The static recycling method only recycles emulator processes with CPU usage less than 10% to the recycling pool when a new emulator process is running. It cannot promptly restore emulator processes already recycled to the recycling pool with CPU usage greater than 10% to idle service cores. This embodiment, based on the static recycling method, executes a dynamic recycling method when no service cores are idle. By periodically querying CPU usage, it recycles emulator processes with CPU usage less than 10% to the recycling pool; and promptly restores emulator processes in the recycling pool with CPU usage greater than 10% to idle service cores. The dynamic recycling process occurs when no service cores are idle.

[0134] To facilitate the emulator process transfer and core binding process, this embodiment pre-constructs a process ID mapping table: a data structure is constructed to record the process ID information of the emulator processes bound to each fixed core, thus realizing the process ID mapping table construction; after the terminal (which can be a server) where the emulator process is located restarts, the recycling pool data is initialized, and all process IDs in the process ID mapping table are cleared to zero. In an optional implementation, each fixed core can bind 10 emulator processes. Table 3 is the process ID mapping table stored in the data structure. Each row represents the fixed core number, which is 8, 9, 40, 41 in sequence. Each column represents the process ID information stored on that fixed core. After the server restarts, the recycling pool data is initialized once, and all process IDs are cleared to 0.

[0135] Table 3: Process ID Mapping Relationship Table in Data Structure

[0136]

[0137] Figure 6 This is a schematic diagram of the emulator process transfer and core binding process, which includes the following steps.

[0138] Step 1: Get the list of newly added emulator processes.

[0139] Step 2: Determine if the list of newly added emulator processes is empty. If not, wait for a preset time and return to Step 1. If yes, obtain the process ID information that is not 0 from the process ID mapping table and record it in the second file.

[0140] For example, if the list of newly added emulator processes is not empty, wait 5 minutes to proceed to step 1, so as to realize dynamic process recycling when no new emulator processes are added.

[0141] Step 3: Determine if there is a next process ID in the second file. If not, wait for a preset time and return to Step 1. If yes, proceed to Step 4.

[0142] Step 4: Query the CPU usage of the emulator process with the next process ID information, and determine whether the CPU usage is greater than or equal to the usage threshold. If not, return to step 3; otherwise, proceed to step 5.

[0143] For example, if there is no next process ID information in the second file, wait 5 minutes and proceed to step 1. If there is next process ID information in the second file, query the CPU usage of the next emulator process. If the CPU usage is less than 10%, there is no need to transfer, and proceed to step 3 to continue the judgment. If the CPU usage is greater than or equal to 10%, continue to the next step and transfer the next emulator process to an idle service core.

[0144] Step 5: Query the fixed core information bound to the emulator process of the next process ID information.

[0145] Step 6: Obtain the number of idle service cores.

[0146] Step 7: Determine if the number of idle service cores is greater than or equal to 1. If yes, proceed to step 8; otherwise, proceed to step 10.

[0147] Step 8: Release the simulator process with the next process ID from the recycling pool.

[0148] Step 9: Determine if the release from the recycling pool was successful. If so, return to step 3; otherwise, wait for the preset time and then return to step 1.

[0149] Step 10: Obtain information on all emulator processes and filter out the process ID and CPU usage of all currently running emulator processes.

[0150] Step 11: Save the filtered emulator process information to a third file.

[0151] Step 12: Check if there is a next emulator process information in the third file. If there is, proceed to step 13; otherwise, proceed to step 17.

[0152] Step 13: Determine if the CPU utilization of the next emulator process is less than the utilization threshold. If so, execute only step 14; otherwise, return to step 12.

[0153] Step 14: Determine whether the CPU core bound to the next emulator process is a business core. If so, proceed to step 15; otherwise, return to step 12.

[0154] Step 15: Recycle the next emulator process into the recycling pool.

[0155] Step 16: Determine whether the recycling pool has successfully recycled. If so, return to step 12; otherwise, exit abnormally and proceed to step 17.

[0156] Step 17: Count the number of idle service cores.

[0157] Step 18: Determine if the number of idle service cores is greater than or equal to 1. If so, proceed to step 8; otherwise, wait for a preset time and return to step 1.

[0158] When transferring the next emulator process to an idle service core, if an idle service core exists, the next emulator process is directly released from the recycling pool (the release process will be described in detail later). If no idle service core exists, the emulator process with CPU utilization less than 10% is unbound from the service core and transferred to a fixed core to obtain an idle service core. Then, the next emulator process is transferred to the idle service core. The preset waiting time in this embodiment is 5 minutes.

[0159] Part Four: Reclaiming and Releasing Emulator Processes.

[0160] (1) Recycle the emulator process into the recycling pool.

[0161] Figure 7 This is a flowchart illustrating the process of recycling emulator processes to the recycling pool, which includes the following steps.

[0162] Step 1: Obtain the emulator process information that needs to be recycled and set the recycling flag to 0.

[0163] Step 2: Loop through the process ID mapping table to find the first element with process ID 0, mark it as the target element, and execute Step 3; if no element with process ID 0 is found, no setting is performed.

[0164] Step 3: Bind the simulator process to be recycled to the fixed core corresponding to the target element, unbind the simulator process to be recycled from the business core, record the business core status as idle, fill the process number of the simulator process to be recycled into the target element, set the recycling flag to 1, and exit the loop.

[0165] Step 4: Check the recycling flag. If the recycling flag is 1, record that the recycling was successful; if the recycling flag is 0, record that the recycling failed.

[0166] In one optional implementation, based on the structure of the process ID mapping relationship, when searching in step 2 according to the process ID mapping relationship table, the search is performed from left to right and from top to bottom in one round to find the first element with a process ID of 0.

[0167] (2) Release the emulator process from the recycling pool.

[0168] Figure 8 This is a flowchart illustrating the process of releasing the emulator process from the recycling pool, specifically including the following steps.

[0169] Step 1: Obtain the emulator process information and idle service core number that need to be released, and set the release flag to 0.

[0170] Step 2: Loop through the process ID mapping table to find the element corresponding to the process ID of the emulator process to be released, record it as the target element, and then execute Step 3; if no element corresponding to the process ID of the emulator process to be released is found, no settings are made.

[0171] Step 3: Bind the simulator process to be released to the idle business core and record the business core status as occupied. At the same time, unbind the simulator process to be released from the fixed core, clear the target element, set the release flag to 1, and exit the loop.

[0172] Step 4: Check the release flag. If the release flag is 1, record that the release was successful; if the release flag is 0, record that the release failed.

[0173] In one optional implementation, based on the structure of the process ID mapping relationship, when searching in step 2 according to the process ID mapping relationship table, the search is performed from left to right and from top to bottom in one round to find the element whose current process ID is equal to the unbound process ID.

[0174] It should be noted that, Figure 7 and Figure 8 In this context, i refers to the number of processes that a fixed core can bind, and j refers to the number of fixed cores. In a specific embodiment, the value of i is 0~9, and the value of j is 1~4.

[0175] The above text provides a detailed description of an embodiment of an emulator process monitoring method. Based on the emulator process monitoring method described in the above embodiment, this invention also provides an emulator process monitoring system corresponding to the method.

[0176] Figure 9 This is a schematic block diagram of an emulator process monitoring system provided in an embodiment of the present invention. In this embodiment, the emulator process monitoring system 900 can be divided into multiple functional modules according to the functions it performs. A module, as referred to in this invention, is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory.

[0177] CPU core partitioning module 910: partitions isolated CPU cores, including dividing isolated CPUs into service cores and fixed cores, with all fixed cores forming a recycling pool; among them, service cores are bound one-to-one with simulator processes, and fixed cores are bound one-to-many with simulator processes.

[0178] The new emulator process binding module 920 binds new emulator processes to cores. When a new emulator process is added, if an idle service core exists, the new emulator process is bound to one of the idle service cores. If no idle service core exists, a target service core is selected, the emulator process on the target service core is transferred to a fixed core, and then the new emulator process is bound to one of the target service cores. If no target service core exists, the binding of the new emulator process is terminated. The target service core refers to the service core to which the emulator process bound has a CPU utilization rate lower than the utilization rate threshold.

[0179] Emulator process transfer and core binding module 930: Performs emulator process transfer and core binding, including periodically transferring and binding the emulator process on the target business core to a fixed core when no new emulator processes are added, and transferring and binding the emulator process on the target fixed core to an idle business core; wherein, the target fixed core refers to a fixed core whose CPU utilization of the emulator process bound to it is greater than or equal to the utilization threshold.

[0180] In an optional implementation, the new simulator process binding module 920 is specifically used for: obtaining the process ID of the new simulator process and saving it to the new simulator process list; obtaining the status of each service core and counting the number of idle service cores; determining whether the number of idle service cores is greater than or equal to 1; if so, binding the new simulator process to one of the idle service cores and recording the status of the bound service core as occupied, while deleting the new simulator process from the new simulator process list; if not, filtering the target service cores, transferring the simulator process on the target service core to a fixed core, and then binding the new simulator process to one of the target service cores.

[0181] In one optional implementation, target service cores are selected, the simulator process on the target service core is transferred to a fixed core, and then the newly added simulator process is bound to one of the target service cores. If no target service core exists, the binding of the newly added simulator process is exited. Specifically, this includes:

[0182] Step 1: Obtain information on all emulator processes and filter out the process ID and CPU usage of all currently running emulator processes;

[0183] Step 2: Save the filtered emulator process information to the first file;

[0184] Step 3: Check if there is a next emulator process information in the first file. If there is, proceed to step 4; otherwise, proceed to step 8.

[0185] Step 4: Determine if the CPU utilization of the next emulator process is less than the utilization threshold. If yes, proceed to step 5; otherwise, return to step 3.

[0186] Step 5: Determine whether the CPU core bound to the next emulator process is a business core. If so, proceed to step 6; otherwise, return to step 3.

[0187] Step 6: Recycle the next emulator process into the recycling pool;

[0188] Step 7: Determine whether the recycling pool has successfully recycled. If so, return to step 2; otherwise, exit abnormally and remove the newly added emulator process from the list of newly added emulator processes.

[0189] Step 8: Count the number of idle service cores;

[0190] Step 9: Determine if the number of idle service cores is greater than or equal to 1. If so, bind the newly added emulator process to one of the idle service cores and record the status of the bound service core as occupied. At the same time, delete the newly added emulator process from the list of newly added emulator processes. Otherwise, exit abnormally and delete the newly added emulator process from the list of newly added emulator processes.

[0191] In an optional implementation, the system 900 further includes a mapping table construction module 940 for constructing a process ID mapping table. Specifically, this includes: constructing a data structure to record the process ID information of the simulator processes bound to each fixed core, thereby constructing the process ID mapping table; after the terminal where the simulator process is located restarts, the data in the recycling pool is initialized, and all process IDs in the process ID mapping table are cleared to zero.

[0192] In an optional implementation, the emulator process transfer and core binding module 930 is specifically used to perform the following steps:

[0193] Step 1: Obtain the list of newly added emulator processes;

[0194] Step 2: Determine if the list of newly added emulator processes is empty. If not, wait for a preset time and return to Step 1. If yes, obtain the process ID information that is not 0 from the process ID mapping table and record it in the second file.

[0195] Step 3: Determine if there is a next process ID in the second file. If not, wait for a preset time and return to Step 1. If yes, proceed to Step 4.

[0196] Step 4: Query the CPU usage of the emulator process in the next process ID information, and determine whether the CPU usage is greater than or equal to the usage threshold. If not, return to step 3; otherwise, proceed to step 5.

[0197] Step 5: Query the fixed core information bound to the emulator process of the next process ID information;

[0198] Step 6: Obtain the number of idle service cores;

[0199] Step 7: Determine if the number of idle service cores is greater than or equal to 1. If yes, proceed to step 8; otherwise, proceed to step 10.

[0200] Step 8: Release the simulator process with the next process ID from the recycling pool;

[0201] Step 9: Determine whether the release from the recycling pool was successful. If so, return to step 3; otherwise, wait for the preset time and then return to step 1.

[0202] Step 10: Obtain information on all emulator processes and filter out the process ID and CPU usage of all currently running emulator processes.

[0203] Step 11: Save the filtered emulator process information to a third file;

[0204] Step 12: Check if there is a next emulator process information in the third file. If there is, proceed to step 13; otherwise, proceed to step 17.

[0205] Step 13: Determine if the CPU utilization of the next emulator process is less than the utilization threshold. If so, execute only step 14; otherwise, return to step 12.

[0206] Step 14: Determine whether the CPU core bound to the next emulator process is a business core. If so, proceed to step 15; otherwise, return to step 12.

[0207] Step 15: Recycle the next emulator process into the recycling pool;

[0208] Step 16: Determine whether the recycling pool has successfully recycled. If so, return to step 12; otherwise, exit abnormally and proceed to step 17.

[0209] Step 17: Count the number of idle service cores;

[0210] Step 18: Determine if the number of idle service cores is greater than or equal to 1. If so, proceed to step 8; otherwise, wait for a preset time and return to step 1.

[0211] In an optional implementation, system 900 further includes a process recycling module 950 for recycling emulator processes to a recycling pool, specifically including:

[0212] Step 1: Obtain the emulator process information that needs to be recycled, and set the recycling flag to 0;

[0213] Step 2: Loop through the process ID mapping table to find the first element with process ID 0, mark it as the target element, and proceed to Step 3; if no element with process ID 0 is found, no setting is performed.

[0214] Step 3: Bind the simulator process to be recycled to the fixed core corresponding to the target element, unbind the simulator process to be recycled from the business core, record the business core status as idle, fill the process number of the simulator process to be recycled into the target element, set the recycling flag to 1, and exit the loop.

[0215] Step 4: Check the recycling flag. If the recycling flag is 1, record that the recycling was successful; if the recycling flag is 0, record that the recycling failed.

[0216] In an optional implementation, system 900 further includes a process release module 960, which releases the emulator process from the recycling pool, specifically including:

[0217] Step 1: Obtain the emulator process information and idle service core number that need to be released, and set the release flag to 0;

[0218] Step 2: Loop through the process ID mapping table to find the element corresponding to the process ID of the emulator process to be released, record it as the target element, and then execute Step 3; if no element corresponding to the process ID of the emulator process to be released is found, no settings are made.

[0219] Step 3: Bind the simulator process to be released to the idle business core and record the business core status as occupied. At the same time, unbind the simulator process to be released from the fixed core, clear the target element, set the release flag to 1, and exit the loop.

[0220] Step 4: Check the release flag. If the release flag is 1, record that the release was successful; if the release flag is 0, record that the release failed.

[0221] The simulator process monitoring system of this embodiment is used to implement the aforementioned simulator process monitoring method. Therefore, the specific implementation of this system can be found in the embodiment section of the simulator process monitoring method above. Thus, the specific implementation can be referred to the description of the corresponding embodiments, and will not be elaborated here.

[0222] Furthermore, since the simulator process monitoring system in this embodiment is used to implement the aforementioned simulator process monitoring method, its function corresponds to the function of the above method, and will not be described again here.

[0223] Figure 10 A schematic diagram of a terminal 1000 provided in an embodiment of the present invention includes: a processor 1010, a memory 1020, and a communication unit 1030. The processor 1010 is used to implement the following steps when executing the simulator process monitoring program stored in the memory 1020:

[0224] (1) The steps for dividing the isolated CPU cores;

[0225] The isolated CPU is divided into business cores and fixed cores, and all fixed cores form a recycling pool; the business cores are bound one-to-one with the simulator processes, and the fixed cores are bound one-to-many with the simulator processes.

[0226] (2) Steps for adding a new emulator process bound to a core;

[0227] When a new emulator process is added, if there are idle service cores, the new emulator process is bound to one of the idle service cores. If there are no idle service cores, a target service core is selected, the emulator process on the target service core is transferred to a fixed core, and the new emulator process is bound to one of the target service cores. If there are no target service cores, the binding of the new emulator process is terminated. Here, the target service core refers to the service core to which the emulator process bound has a CPU utilization rate less than the utilization rate threshold.

[0228] (3) Steps for transferring the emulator process to the bound core;

[0229] When no new simulator processes are added, the simulator processes on the target business core are periodically transferred and bound to a fixed core, and the simulator processes on the target fixed core are transferred and bound to an idle business core. The target fixed core refers to a fixed core whose CPU utilization rate of the simulator process bound to it is greater than or equal to the utilization rate threshold.

[0230] The present invention also provides a computer storage medium, which may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM), etc.

[0231] The computer storage medium stores an emulator process monitoring program, which, when executed by the processor, performs the following steps:

[0232] (1) The steps for dividing the isolated CPU cores;

[0233] The isolated CPU is divided into business cores and fixed cores, and all fixed cores form a recycling pool; the business cores are bound one-to-one with the simulator processes, and the fixed cores are bound one-to-many with the simulator processes.

[0234] (2) Steps for adding a new emulator process bound to a core;

[0235] When a new emulator process is added, if there are idle service cores, the new emulator process is bound to one of the idle service cores. If there are no idle service cores, a target service core is selected, the emulator process on the target service core is transferred to a fixed core, and the new emulator process is bound to one of the target service cores. If there are no target service cores, the binding of the new emulator process is terminated. Here, the target service core refers to the service core to which the emulator process bound has a CPU utilization rate less than the utilization rate threshold.

[0236] (3) Steps for transferring the emulator process to the bound core;

[0237] When no new simulator processes are added, the simulator processes on the target business core are periodically transferred and bound to a fixed core, and the simulator processes on the target fixed core are transferred and bound to an idle business core. The target fixed core refers to a fixed core whose CPU utilization rate of the simulator process bound to it is greater than or equal to the utilization rate threshold.

[0238] The above-disclosed embodiments are merely preferred embodiments of the present invention, but the present invention is not limited thereto. Any non-creative variations that can be conceived by those skilled in the art, as well as any improvements and modifications made without departing from the principles of the present invention, should fall within the protection scope of the present invention.

Claims

1. A method for monitoring emulator processes, characterized in that, Includes the following steps: (1) The steps for dividing the isolated CPU cores; The isolated CPU is divided into business cores and fixed cores, and all fixed cores form a recycling pool; the business cores are bound one-to-one with the simulator processes, and the fixed cores are bound one-to-many with the simulator processes. (2) Steps for adding a new emulator process bound to a core; When a new emulator process is added, if there are idle service cores, the new emulator process is bound to one of the idle service cores. If there are no idle service cores, a target service core is selected, the emulator process on the target service core is transferred to a fixed core, and the new emulator process is bound to one of the target service cores. If there are no target service cores, the binding of the new emulator process is terminated. Here, the target service core refers to the service core to which the emulator process bound has a CPU utilization rate less than the utilization rate threshold. (3) Steps for transferring the emulator process to the bound core; When no new simulator processes are added, the simulator processes on the target business core are periodically transferred and bound to a fixed core, and the simulator processes on the target fixed core are transferred and bound to an idle business core. The target fixed core refers to a fixed core whose CPU utilization rate of the simulator process bound to it is greater than or equal to the utilization rate threshold.

2. The emulator process monitoring method according to claim 1, characterized in that, If an idle service core exists, the newly added emulator process will be bound to one of the idle service cores. If no idle service core exists, a target service core will be selected, the emulator process on the target service core will be transferred to a fixed core, and then the newly added emulator process will be bound to one of the target service cores. Specifically, this includes: Get the process ID of the newly added emulator process and save it to the list of newly added emulator processes; Obtain the status of each service core and count the number of idle service cores; Determine if the number of idle service cores is greater than or equal to 1; If so, the newly added simulator process will be bound to one of the idle business cores, and the status of the bound business core will be recorded as occupied. At the same time, the newly added simulator process will be deleted from the list of newly added simulator processes. If not, then filter the target business cores, transfer the simulator process on the target business core to a fixed core, and then bind the newly added simulator process to one of the target business cores.

3. The simulator process monitoring method according to claim 2, characterized in that, Filter target business cores, transfer the simulator process on the target business core to a fixed core, and then bind the newly added simulator process to one of the target business cores. If no target business core exists, exit the process of binding the new simulator process. Specifically, this includes: Step 1: Obtain information on all emulator processes and filter out the process ID and CPU usage of all currently running emulator processes; Step 2: Save the filtered emulator process information to the first file; Step 3: Check if there is a next emulator process information in the first file. If there is, proceed to step 4; otherwise, proceed to step 8. Step 4: Determine if the CPU utilization of the next emulator process is less than the utilization threshold. If yes, proceed to step 5; otherwise, return to step 3. Step 5: Determine whether the CPU core bound to the next emulator process is a business core. If so, proceed to step 6; otherwise, return to step 3. Step 6: Recycle the next emulator process into the recycling pool; Step 7: Determine whether the recycling pool has successfully recycled. If so, return to step 2; otherwise, exit abnormally and remove the newly added emulator process from the list of newly added emulator processes. Step 8: Count the number of idle service cores; Step 9: Determine if the number of idle service cores is greater than or equal to 1. If so, bind the newly added emulator process to one of the idle service cores and record the status of the bound service core as occupied. At the same time, delete the newly added emulator process from the list of newly added emulator processes. Otherwise, exit abnormally and delete the newly added emulator process from the list of newly added emulator processes.

4. The emulator process monitoring method according to claim 3, characterized in that, The method also includes the step of constructing a process ID mapping table, specifically including: Construct a data structure to record the process ID information of the emulator processes bound to each fixed core, and build a process ID mapping table; After the terminal where the emulator process is located restarts, the data in the recycling pool is initialized, and all process IDs in the process ID mapping table are cleared to zero.

5. The emulator process monitoring method according to claim 4, characterized in that, When no new simulator processes are added, the simulator processes on the target service core are periodically transferred and bound to a fixed core, and the simulator processes on the target fixed core are transferred and bound to an idle service core. Specifically, this includes: Step 1: Obtain the list of newly added emulator processes; Step 2: Determine if the list of newly added emulator processes is empty. If not, wait for a preset time and return to Step 1. If yes, obtain the process ID information that is not 0 from the process ID mapping table and record it in the second file. Step 3: Determine if there is a next process ID in the second file. If not, wait for a preset time and return to Step 1. If yes, proceed to Step 4. Step 4: Query the CPU usage of the emulator process in the next process ID information, and determine whether the CPU usage is greater than or equal to the usage threshold. If not, return to step 3; otherwise, proceed to step 5. Step 5: Query the fixed core information bound to the emulator process of the next process ID information; Step 6: Obtain the number of idle service cores; Step 7: Determine if the number of idle service cores is greater than or equal to 1. If yes, proceed to step 8; otherwise, proceed to step 10. Step 8: Release the simulator process with the next process ID from the recycling pool; Step 9: Determine whether the release from the recycling pool was successful. If so, return to step 3; otherwise, wait for the preset time and then return to step 1. Step 10: Obtain information on all emulator processes and filter out the process ID and CPU usage of all currently running emulator processes. Step 11: Save the filtered emulator process information to a third file; Step 12: Check if there is a next emulator process information in the third file. If there is, proceed to step 13; otherwise, proceed to step 17. Step 13: Determine if the CPU utilization of the next emulator process is less than the utilization threshold. If so, execute only step 14; otherwise, return to step 12. Step 14: Determine whether the CPU core bound to the next emulator process is a business core. If so, proceed to step 15; otherwise, return to step 12. Step 15: Recycle the next emulator process into the recycling pool; Step 16: Determine whether the recycling pool has successfully recycled. If so, return to step 12; otherwise, exit abnormally and proceed to step 17. Step 17: Count the number of idle service cores; Step 18: Determine if the number of idle service cores is greater than or equal to 1. If so, proceed to step 8; otherwise, wait for a preset time and return to step 1.

6. The emulator process monitoring method according to claim 5, characterized in that, The emulator process is recycled to the recycling pool, specifically including: Step 1: Obtain the emulator process information that needs to be recycled, and set the recycling flag to 0; Step 2: Loop through the process ID mapping table to find the first element with process ID 0, mark it as the target element, and proceed to Step 3; if no element with process ID 0 is found, no setting is performed. Step 3: Bind the simulator process to be recycled to the fixed core corresponding to the target element, unbind the simulator process to be recycled from the business core, record the business core status as idle, fill the process number of the simulator process to be recycled into the target element, set the recycling flag to 1, and exit the loop. Step 4: Check the recycling flag. If the recycling flag is 1, record that the recycling was successful; if the recycling flag is 0, record that the recycling failed.

7. The simulator process monitoring method according to claim 5, characterized in that, Releasing the emulator process from the recycling pool includes: Step 1: Obtain the emulator process information and idle service core number that need to be released, and set the release flag to 0; Step 2: Loop through the process ID mapping table to find the element corresponding to the process ID of the emulator process to be released, record it as the target element, and then execute Step 3; if no element corresponding to the process ID of the emulator process to be released is found, no settings are made. Step 3: Bind the simulator process to be released to the idle business core and record the business core status as occupied. At the same time, unbind the simulator process to be released from the fixed core, clear the target element, set the release flag to 1, and exit the loop. Step 4: Check the release flag. If the release flag is 1, record that the release was successful; if the release flag is 0, record that the release failed.

8. A simulator process monitoring system, characterized in that, include, CPU core partitioning module: This module partitions isolated CPU cores, including dividing isolated CPUs into service cores and fixed cores. All fixed cores form a recycling pool. The business core is bound to the simulator process in a one-to-one manner, while the fixed core is bound to the simulator process in a one-to-many manner. The module adds a core binding feature for new emulator processes. This involves binding new emulator processes to specific cores. If an idle business core exists, the new emulator process is bound to it. If no idle business core exists, a target business core is selected, and the emulator process on that target core is transferred to a fixed core. The new emulator process is then bound to one of the target business cores. If no target business core exists, the binding process is terminated. The target business core refers to the business core to which the bound emulator process has a CPU utilization rate below a certain threshold. Emulator process transfer and core binding module: Performs emulator process transfer and core binding, including periodically transferring and binding the emulator process on the target business core to a fixed core when no new emulator processes are added, and transferring and binding the emulator process on the target fixed core to an idle business core; where the target fixed core refers to a fixed core whose CPU utilization of the emulator process bound to it is greater than or equal to the utilization threshold.

9. A terminal, characterized in that, include: Memory, used to store the emulator process monitoring program; A processor, configured to implement the steps of the simulator process monitoring method as described in any one of claims 1-7 when executing the simulator process monitoring program.

10. A computer-readable storage medium, characterized in that, The readable storage medium stores an emulator process monitoring program, which, when executed by a processor, implements the steps of the emulator process monitoring method as described in any one of claims 1-7.

Images