Simulator process monitoring method and system, terminal and medium

Abstract

The invention relates to the field of simulator monitoring, and particularly discloses a simulator process monitoring method and system, a terminal and a medium, business cores and processes are bound in a one-to-one manner, and fixed cores and processes are bound in a one-to-many manner; and when a new process exists, executing a recovery pool static recovery method which comprises the following steps: if a service core is idle, binding the new process with the idle service core, and if no service core is idle, unbinding the process of which the current CPU utilization rate is less than a threshold value with the bound service core to release the service core, and then binding the new process with the idle service core. And when no new process is added, executing a recovery pool dynamic recovery method which comprises the following steps: recovering and binding the process with the CPU utilization rate greater than or equal to a threshold value on the fixed core to the idle service core, and binding the process with the CPU utilization rate less than the threshold value on the service core to the fixed core. According to the method, the processes with low CPU utilization rate are bound to the fixed cores, so that the fixed cores and the processes are bound in a one-to-many mode, the number of the processes running at the same time is increased, and the CPU resource utilization rate is increased.

Description

Technical Field

[0001] The present invention relates to the field of simulator monitoring, and in particular to a simulator process monitoring method, system, terminal and medium. Background Art

[0002] In the early stage of chip design, before the chip is taped out, in order to verify the function of the chip, the chip design will be verified in multiple dimensions through simulation. Among them, using the QEMU simulator (hereinafter referred to as: simulator) to verify the chip design is one way.

[0003] As an executable file, the simulator runs as a process when the operating system pulls it. The simulator process is scheduled by the operating system and needs to follow the operating system's scheduling rules. When the CPU usage of other processes running on the operating system is high, the CPU usage of the corresponding simulator process will decrease, and the stability of the simulator process cannot be guaranteed at this time. The CPU usage of the simulator process will be limited by the operating system scheduling rules and other processes. Once the simulator processes are pulled up in batches and there is no idle CPU resource allocation, the performance of the simulator will decrease.

[0004] In order to provide a stable and available simulator test environment whose performance is not affected by the operating system, the server's CPU core is usually isolated and the simulator process is bound to the isolated CPU core. When server resources are limited and each server provides a limited number of CPU cores for isolation and binding, there will be the following problems when pulling the simulator process: 1) When the simulator process is bound to the CPU core one-to-one, the number of simulator processes running at the same time is at most the number of isolated CPU cores, and the number of simulator processes is limited by the CPU core; 2) If the binding relationship between the simulator process and the CPU core remains unchanged, when the user only performs a small amount of operations on the simulator, the CPU usage of the simulator process is low, resulting in a waste of CPU resources. Summary of the invention

[0005] To solve the above problems, the present invention provides a simulator process monitoring method, system, terminal and medium, which bind the simulator process with low CPU utilization rate to the fixed core, so that the fixed core and the simulator process are bound one-to-many, thereby increasing the number of simulator processes running simultaneously and improving CPU resource utilization.

[0006] In a first aspect, the technical solution of the present invention provides a simulator process monitoring method, comprising the following steps: (1) Steps for partitioning isolated CPU cores; The isolated CPU is divided into business cores and fixed cores, and all fixed cores form a recycling pool. Business cores are bound to simulator processes one-to-one, and fixed cores are bound to simulator processes one-to-many. (2) Added the steps of binding the simulator process to the core; When a new simulator process is added, if there are idle business cores, the new simulator process will be bound to one of the idle business cores. If there are no idle business cores, the target business cores will be screened, and the simulator process on the target business core will be transferred to the fixed core, and then the new simulator process will be bound to one of the target business cores. If there is no target business core, the binding of the new simulator process will be exited; wherein, the target business core refers to the business core whose CPU usage of the simulator process bound to it is less than the usage threshold; (3) Steps for transferring the simulator process to bind the core; When there is no new simulator process, the simulator process on the target business core is periodically transferred and bound to the fixed core, and the simulator process on the target fixed core is transferred and bound to the idle business core; wherein the target fixed core refers to a fixed core whose CPU usage of the simulator process bound to it is greater than or equal to the usage threshold.

[0007] In an optional implementation, if there is an idle business core, the newly added simulator process is bound to one of the idle business cores; if there is no idle business core, the target business core is screened, the simulator process on the target business core is transferred to the fixed core, and then the newly added simulator process is bound to one of the target business cores, specifically including: Get the process ID of the newly added simulator process and save it to the newly added simulator process list; Obtain the status of each business core and count the number of idle business cores; Determine whether the number of idle business cores is greater than or equal to 1; If yes, the newly added simulator process is bound to one of the idle business cores, and the state of the bound business core is recorded as occupied, and the newly added simulator process is deleted from the newly added simulator process list; If not, the target business core is selected, the simulator process on the target business core is transferred to the fixed core, and then the newly added simulator process is bound to one of the target business cores.

[0008] In an optional implementation, the target business core is screened, the simulator process on the target business core is transferred to the fixed core, and then the newly added simulator process is bound to one of the target business cores. If the target business core does not exist, the newly added simulator process binding is exited, specifically including: Step 1, obtain all simulator process information, and filter out the process ID and CPU usage of all currently running simulator processes; Step 2, saving the filtered simulator process information into a first file; Step 3, query whether there is the next simulator process information in the first file, if yes, execute step 4, otherwise execute step 8; Step 4, determine whether the CPU usage of the next simulator process is less than the usage threshold, if so, execute step 5, otherwise return to step 3; Step 5, determine whether the CPU core bound to the next simulator process is a business core, if so, execute step 6, otherwise return to step 3; Step 6, recycle the next simulator process to the recycling pool; Step 7, determine whether the recycling pool is successfully recycled, if so, return to step 2, otherwise exit abnormally and delete the newly added simulator process from the newly added simulator process list; Step 8: Count the number of idle service cores; Step 9, determine whether the number of idle business cores is greater than or equal to 1. If so, bind the newly added simulator process to one of the idle business cores, and record the status of the bound business core as occupied. At the same time, delete the newly added simulator process from the list of newly added simulator processes; otherwise, exit abnormally and delete the newly added simulator process from the list of newly added simulator processes.

[0009] In an optional implementation, the method further includes the step of constructing a process number mapping relationship table, specifically including: Construct a data structure to record the process number information of the simulator process bound to each fixed core and implement the process number mapping relationship table construction; After the terminal where the simulator process is located is restarted, the recycling pool data is initialized and all process numbers in the process number mapping table are cleared.

[0010] In an optional implementation, when there is no new simulator process, the simulator process on the target service core is periodically transferred and bound to the fixed core, and the simulator process on the target fixed core is transferred and bound to the idle service core, specifically including: Step 1, get the new simulator process list; Step 2, determine whether the newly added simulator process list is empty, if not, wait for a preset time and return to step 1, if yes, obtain the process number information that is not 0 in the process number mapping table, and record it in the second file; Step 3, determine whether there is the next process number information in the second file, if not, wait for a preset time and return to step 1, if yes, execute step 4; Step 4, query the CPU usage of the simulator process of the next process number information, and determine whether the CPU usage is greater than or equal to the usage threshold, if not, return to step 3, if yes, execute step 5; Step 5, query the fixed core information bound to the simulator process of the next process number information; Step 6: Obtain the number of idle service cores; Step 7, determine whether the number of idle service cores is greater than or equal to 1, if so, execute step 8, otherwise execute step 10; Step 8, releasing the simulator process of the next process number information from the recycling pool; Step 9, determine whether the release of the recycling pool is successful, if so, return to step 3, otherwise wait for a preset time and return to step 1; Step 10, obtain all simulator process information, and filter out the process ID and CPU usage of all currently running simulator processes; Step 11, saving the filtered simulator process information into a third file; Step 12, query whether there is a next simulator process information in the third file, if yes, execute step 13, otherwise execute step 17; Step 13, determine whether the CPU usage of the next simulator process is less than the usage threshold, if so, only execute step 14, otherwise return to step 12; Step 14, determine whether the CPU core bound to the next simulator process is a business core, if so, execute step 15, otherwise return to step 12; Step 15, recycle the next simulator process to the recycling pool; Step 16, determine whether the recycling pool is successfully recycled, if so, return to step 12, otherwise exit abnormally and execute step 17; Step 17, counting the number of idle service cores; Step 18, determine whether the number of idle service cores is greater than or equal to 1, if so, execute step 8, otherwise wait for a preset time and return to step 1.

[0011] In an optional implementation, recycling the simulator process to a recycling pool specifically includes: Step 1, obtain the simulator process information that needs to be recycled, and set the recycling flag to 0; Step 2: Loop through the process number mapping table to find the first element with process number 0, record it as the target element, and execute step 3; if no element with process number 0 is found, do not set it; 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 mark, if the recycling mark is 1, record the recycling success, if the recycling mark is 0, record the recycling failure.

[0012] In an optional implementation, releasing the simulator process from the recycling pool specifically includes: Step 1, obtain the simulator process information and idle service core number to be released, and set the release flag to 0; Step 2: Search the process number mapping table in a loop to find the element corresponding to the process number of the simulator process to be released, record it as the target element, and execute step 3; if the element corresponding to the process number of the simulator process to be released is not found, no setting is made; Step 3: Bind the simulator process to be released to the idle business core, record the business core status as occupied, and 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 the release success, if the release flag is 0, record the release failure.

[0013] In a second aspect, the technical solution of the present invention provides a simulator process monitoring system, comprising: CPU core division module: divides the isolated CPU core into business cores and fixed cores. All fixed cores form a recycling pool. Business cores are bound to simulator processes one-to-one, and fixed cores are bound to simulator processes one-to-many. New simulator process binding core module: bind the new simulator process to the core, including when there is a new simulator process, if there is an idle business core, bind the new simulator process to one of the idle business cores, if there is no idle business core, filter the target business core, transfer the simulator process on the target business core to the fixed core, and then bind the new simulator process to one of the target business cores, if there is no target business core, exit the binding of the new simulator process; where the target business core refers to the business core whose CPU usage of the simulator process bound to it is less than the usage threshold; Simulator process transfer and core binding module: performs simulator process transfer and core binding, including periodically transferring and binding the simulator process on the target business core to a fixed core when there is no new simulator process, and transferring and binding the simulator process on the target fixed core to an idle business core; wherein, the target fixed core refers to a fixed core whose CPU usage of the simulator process bound to it is greater than or equal to the usage threshold.

[0014] In a third aspect, the technical solution of the present invention provides a terminal, including: A memory, used for storing a simulator process monitoring program; A processor is used to implement the steps of the simulator process monitoring method as described in any one of the above items when executing the simulator process monitoring program.

[0015] In a fourth aspect, the technical solution of the present invention provides a computer-readable storage medium, on which a simulator process monitoring program is stored, and when the simulator process monitoring program is executed by a processor, the steps of the simulator process monitoring method as described in any one of the above items are implemented.

[0016] Compared with the prior art, the simulator process monitoring method, system, terminal and medium provided by the present invention have the following beneficial effects: first, the isolated CPU core is divided into business core and fixed core, and on this basis, the simulator process with low CPU utilization rate is bound to the fixed core, so that the fixed core and the simulator process are bound one-to-many, and resource allocation can be flexibly adjusted dynamically according to the needs of the simulator process. When the business core resources are tight, the low-load simulator process can be efficiently migrated to the fixed core, thereby releasing the business core resources to accommodate new processes, increasing the number of simulator processes running simultaneously, and significantly improving the overall utilization of CPU resources. BRIEF DESCRIPTION OF THE DRAWINGS In order to more clearly illustrate the embodiments of the present invention or the technical solutions of the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0017] Figure 1 It is a flow chart of a simulator process monitoring method provided by an embodiment of the present invention.

[0018] Figure 2 This is a schematic diagram of processes binding CPU cores on the server.

[0019] Figure 3 This is a schematic diagram of the server CPU core division.

[0020] Figure 4 This is a schematic diagram of business core state transfer.

[0021] Figure 5 This is a schematic diagram of the new simulator process binding core flow.

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

[0023] Figure 7 It is a flowchart of recycling the simulator process to the recycling pool.

[0024] Figure 8 It is a flowchart of releasing the simulator process from the recycling pool.

[0025] Fig. 9The present invention provides a simulator process monitoring system structure schematic diagram.

[0026] Fig.10 It is a schematic diagram of the structure of a terminal provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0027] In order to enable those skilled in the art to better understand the scheme of the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and specific implementation methods. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used in the specification of the present invention herein are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0029] The key terms appearing in the present invention are explained below.

[0030] QEMU: It is the abbreviation of "Quick EMUlator", which is an open source, cross-platform, system emulator and simulator.

[0031] Emulator: A pure software hardware device emulated using QEMU. It is an executable file that runs on an x86 Linux or Windows operating system.

[0032] Core binding: In Linux, "core binding" means binding a specific process or thread to a specific CPU core to run, so as to control and optimize system performance, resource allocation and load balancing.

[0033] Unbinding: Unbinding refers to unbinding a process or thread that is bound to a specific CPU core.

[0034] CPU Utilization: is a measure of the amount of time the CPU spends performing various tasks and processes on the computer.

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

[0036] CPU core: the number of CPU cores.

[0037] Figure 1 This is a flow chart of a simulator process monitoring method provided by an embodiment of the present invention. Figure 1 The execution subject may be a simulator process monitoring system. The simulator process monitoring method provided by the embodiment of the present invention is executed by a computer device, and accordingly, the simulator process monitoring system runs in the computer device. According to different requirements, the order of the steps in the flowchart can be changed, and some can be omitted.

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

[0039] S1, a step of dividing the isolated CPU core; The isolated CPU is divided into business cores and fixed cores, and all fixed cores constitute a recycling pool; the business cores are bound to the simulator process one-to-one, and the fixed cores are bound to the simulator process one-to-many.

[0040] S2, add the step of binding the simulator process to the core; When a new simulator process is added, if there are idle business cores, the new simulator process will be bound to one of the idle business cores. If there are no idle business cores, the target business cores will be screened, and the simulator process on the target business core will be transferred to the fixed core, and then the new simulator process will be bound to one of the target business cores. If there is no target business core, the binding of the new simulator process will be exited; among which, the target business core refers to the business core whose CPU usage of the simulator process bound to it is less than the usage threshold.

[0041] S3, the step of transferring the simulator process to bind the core; When there is no new simulator process, the simulator process on the target business core is periodically transferred and bound to the fixed core, and the simulator process on the target fixed core is transferred and bound to the idle business core; wherein the target fixed core refers to a fixed core whose CPU usage of the simulator process bound to it is greater than or equal to the usage threshold.

[0042] Under actual conditions, the CPU usage of each simulator process will change with the actual user usage. For example, when the user is using the simulator for debugging, the time interval between instructions sent to the simulator is long, and the CPU usage is low. When the user is using the simulator for testing, the time interval between instructions sent to the simulator is short, and the CPU usage is high. This embodiment takes into account the different CPU usages of different simulator processes. When server resources are limited, the isolated CPU cores are divided into business cores and fixed cores, and simulator processes with lower CPU usage are bound to fixed cores, so that one fixed core can be bound to multiple simulator processes, and simulator processes with higher CPU usage are bound to business cores, so that more simulator processes can be run while ensuring simulator performance, thereby improving CPU resource utilization.

[0043] In order to further understand the present invention, each of the above steps is described in detail below.

[0044] In the first part, the isolated CPU cores are divided.

[0045] Figure 2 This is a schematic diagram of binding CPU cores to processes on the server. The CPU cores on the server are isolated, and some CPU cores are isolated for binding simulator processes. The non-isolated CPU cores are used for normal scheduling of the operating system and for binding server and operating system processes. The isolated CPU cores are divided into business cores and fixed cores, and all fixed cores form a recycling pool. Business cores are bound to simulator processes one-to-one, and fixed cores are bound to simulator processes one-to-many.

[0046] Figure 3 This is a schematic diagram of server CPU core division. Modify the isolcpus parameter to isolate the server CPU cores. For example, isolcpus=8-31,41-63. Save and restart the operating system. The isolated CPU cores are re-divided into business cores 10~31,42~63. The fixed cores are 8,9,41,42 and form a recycling pool.

[0047] The simulator process is bound to the business core one-to-one, so a maximum of 44 simulator processes can be bound at the same time. Taking the simulator process CPU usage rate less than 10% as the critical value, a fixed core in the recycling pool can recycle a maximum of 10 simulator processes at the same time, so the recycling pool can recycle a maximum of 40 simulator processes at the same time.

[0048] The service core status of this embodiment is divided into three states: idle, occupied, and to be released. The three states can be transferred: the idle state can be transferred to the occupied state, the occupied state can be transferred to the to be released state, and the to be released state can be transferred to the idle state. Figure 4 This is a schematic diagram of the business core state transfer. The idle state is the state without a bound simulator process, the occupied state is the state with a bound simulator process, and the pending release state is the state when the CPU occupancy rate of the simulator process is less than 10% and the simulator process is waiting to be transferred to a fixed core.

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

[0050] Table 1: Service core status

[0051] After the server is restarted, the status of all service cores is set to 0, that is, idle, and recorded in the file, as shown in Table 2.

[0052] Table 2: Business core status is set to 0

[0053] When there are new simulator processes, the static recycling method of the recycling pool is executed, including binding the new simulator process to the idle business core if there are idle business cores, and unbinding the simulator process whose current CPU usage is less than the usage threshold from the bound business core if there are no idle business cores, releasing the business core, and then binding the new simulator process to the idle business core. When there are no new simulator processes, the dynamic recycling method of the recycling pool is executed, including restoring the simulator process whose CPU usage is greater than or equal to the usage threshold on the fixed core to the idle business core, and binding the simulator process whose CPU usage is less than the usage threshold on the business core to the fixed core. The usage threshold of this embodiment is set to 10%.

[0054] This embodiment creates a new simulator process list, which is initialized to 0. When a new simulator process is added, the new simulator process is saved to the list. When the new simulator process is completed or exits abnormally, the simulator process is deleted from the new simulator process list.

[0055] The second part is to add a new simulator process to bind the core.

[0056] In this embodiment, when a newly added simulator process is bound to a core, a static recycling method of the recycling pool is adopted: if there is an idle business core, the simulator process is bound to the business core, and the business core status is recorded as occupied. If there is no idle business core, the simulator process CPU usage is cyclically queried, and the simulator process with a CPU usage of less than 10% and bound to the business core is bound to a fixed core in the recycling pool, and the business core is released. After one cycle, another judgment is made. If there is an idle business core, the simulator process is bound to the business core, and the business core status is recorded as occupied. If there is no idle business core, it exits abnormally. Figure 5 This is a schematic diagram of the new simulator process binding core flow, which specifically includes the following steps.

[0057] Step 1, obtain the process ID of the newly added simulator process and save it to the newly added simulator process list.

[0058] Step 2: Get the status of each service core and count the number of idle service cores.

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

[0060] Step 4: If yes, the newly added simulator process is bound to one of the idle business cores, and the state of the bound business core is recorded as occupied. At the same time, the newly added simulator process is deleted from the newly added simulator process list.

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

[0062] Step 5.1, obtain all simulator process information, and filter out the process ID and CPU usage of all currently running simulator processes.

[0063] An optional implementation method is to use the top command to obtain process information. The top command takes the value at a certain moment, assuming that the CPU usage of the simulator process remains unchanged over a period of time.

[0064] Step 5.2, saving the filtered simulator process information into the first file.

[0065] Step 5.3, check whether there is the next simulator process information in the first file, if yes, execute step 5.4, otherwise execute step 5.8.

[0066] Step 5.4, determine whether the CPU usage of the next simulator process is less than the usage threshold, if so, execute step 5.5, otherwise return to step 5.3.

[0067] Step 5.5, determine whether the CPU core bound to the next simulator process is a business core, if so, execute step 5.6, otherwise return to step 5.3.

[0068] Step 5.6, recycle the next simulator process to the recycling pool (the process recycling process will be described in detail later).

[0069] Step 5.7, determine whether the recycling pool is successfully recycled. If so, return to step 5.2, otherwise exit abnormally and delete the newly added simulator process from the newly added simulator process list.

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

[0071] Step 5.9, determine whether the number of idle business cores is greater than or equal to 1. If so, bind the newly added simulator process to one of the idle business cores, and record the status of the bound business core as occupied. At the same time, delete the newly added simulator process from the list of newly added simulator processes; otherwise, exit abnormally and delete the newly added simulator process from the list of newly added simulator processes.

[0072] A specific embodiment, if the next simulator process information exists in the first file, determine whether the CPU usage of the next simulator process is less than 10%, if it is greater than or equal to 10%, re-query whether the next simulator process information exists in the first file, if it is less than 10%, determine whether the bound core number is a business core, if it is not a business core, continue to re-query whether the next simulator process information exists in the first file, if it is a business core, recycle the next simulator process to the recycling pool.

[0073] The third part is the simulator process transfer and core binding.

[0074] The static recycling method of the recycling pool will only recycle simulator processes with a CPU usage rate of less than 10% to the recycling pool when a new simulator process is running. The simulator processes with a CPU usage rate greater than 10% that have been recycled to the recycling pool cannot be promptly restored and bound to the idle business cores. This embodiment is based on the static recycling method of the recycling pool. When no business cores are idle, the dynamic recycling method of the recycling pool is executed. By periodically querying the CPU usage rate, the simulator processes with a CPU usage rate less than 10% can be recycled to the recycling pool; and the simulator processes with a CPU usage rate greater than 10% in the recycling pool can be promptly restored and bound to the idle business cores. When no business cores are idle, the recycling pool performs a dynamic recycling process.

[0075] In order to facilitate the simulator process transfer and core binding process, this embodiment pre-builds a process number mapping relationship table: constructs a data structure to record the process number information of the simulator process bound to each fixed core, and realizes the construction of the process number mapping relationship table; after the terminal (which can be a server) where the simulator process is located is restarted, the recycling pool data is initialized, and all process numbers in the process number mapping relationship table are cleared. An optional implementation method is that each fixed core can be bound to 10 simulator processes. Table 3 is a process number mapping relationship table stored in the data structure. Each row represents the fixed core number, which is 8, 9, 40, and 41 respectively. Each column represents the process number information stored on the fixed core. After the server is restarted, the recycling pool data is initialized once, and all process numbers are cleared to 0.

[0076] Table 3: Process number mapping table stored in the data structure

[0077] Figure 6 This is a flow chart of simulator process transfer and core binding, which specifically includes the following steps.

[0078] Step 1: Get the list of newly added simulator processes.

[0079] Step 2, determine whether the newly added simulator process list is empty. If not, wait for a preset time and return to step 1. If so, obtain the process number information that is not 0 in the process number mapping table and record it in the second file.

[0080] Exemplarily, if the list of newly added simulator processes is not empty, wait for 5 minutes and enter step 1 to implement dynamic process recycling when there is no newly added simulator process.

[0081] Step 3, determine whether there is the next process number information in the second file, if not, wait for a preset time and return to step 1, if yes, execute step 4.

[0082] Step 4, query the CPU usage of the simulator process of the next process number information, and determine whether the CPU usage is greater than or equal to the usage threshold. If not, return to step 3, and if so, execute step 5.

[0083] For example, if there is no next process number information in the second file, wait for 5 minutes and enter step 1. If there is next process number information in the second file, query the CPU usage of the next simulator process. If the CPU usage is less than 10%, there is no need to transfer. Enter step 3 to continue judging. If the CPU usage is greater than or equal to 10%, continue to execute the next step and transfer the next simulator process to the idle business core.

[0084] Step 5, query the fixed core information bound to the simulator process of the next process number information.

[0085] Step 6: Get the number of idle service cores.

[0086] Step 7, determine whether the number of idle business cores is greater than or equal to 1, if so, execute step 8, otherwise execute step 10.

[0087] Step 8: Release the simulator process of the next process ID information from the recycling pool.

[0088] Step 9, determine whether the recycling pool is released successfully, if so, return to step 3, otherwise wait for a preset time and return to step 1.

[0089] Step 10, obtain all simulator process information, and filter out the process ID and CPU usage of all currently running simulator processes.

[0090] Step 11, saving the filtered simulator process information into a third file.

[0091] Step 12, query whether there is the next simulator process information in the third file, if yes, execute step 13, otherwise execute step 17.

[0092] Step 13, determine whether the CPU usage of the next simulator process is less than the usage threshold, if so, only execute step 14, otherwise return to step 12.

[0093] Step 14, determine whether the CPU core bound to the next simulator process is a business core, if so, execute step 15, otherwise return to step 12.

[0094] Step 15: Recycle the next simulator process to the recycling pool.

[0095] Step 16, determine whether the recycling pool is successfully recycled, if so, return to step 12, otherwise exit abnormally and execute step 17.

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

[0097] Step 18, determine whether the number of idle service cores is greater than or equal to 1, if so, execute step 8, otherwise wait for a preset time and return to step 1.

[0098] When transferring the next simulator process to an idle business core, if there is an idle business core, the next simulator process is directly released from the recycling pool (the release process will be described in detail later). If there is no idle business core, the simulator process with a CPU usage rate of less than 10% is unbound from the business core, transferred and bound to a fixed core to obtain an idle business core, and then the next simulator process is transferred to the idle business core. The preset waiting time of this embodiment is 5 minutes.

[0099] The fourth part is the recovery and release of the simulator process.

[0100] (1) Recycle the simulator process to the recycling pool.

[0101] Figure 7 The flowchart of recycling the simulator process to the recycling pool includes the following steps.

[0102] Step 1, obtain the simulator process information that needs to be recycled and set the recycling flag to 0.

[0103] Step 2: Search the process number mapping table in a loop to find the first element with process number 0, record it as the target element, and execute step 3; if no element with process number 0 is found, do not set it.

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

[0105] Step 4, check the recycling mark, if the recycling mark is 1, record the recycling success, if the recycling mark is 0, record the recycling failure.

[0106] An optional implementation method, according to the structure of the process number mapping relationship, when searching in a loop according to the process number mapping relationship table in step 2, a loop search is performed from left to right and from top to bottom to find the first element with a process number of 0.

[0107] (2) Release the simulator process from the recycling pool.

[0108] Figure 8 The flowchart of releasing the simulator process from the recycling pool includes the following steps.

[0109] Step 1: Get the simulator process information and idle service core number that needs to be released, and set the release flag to 0.

[0110] Step 2, search the process number mapping table in a loop to find the element corresponding to the process number of the simulator process to be released, record it as the target element, and execute step 3; if the element corresponding to the process number of the simulator process to be released is not found, no setting is made.

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

[0112] Step 4, check the release flag, if the release flag is 1, record the release success, if the release flag is 0, record the release failure.

[0113] An optional implementation method, according to the structure of the process number mapping relationship, when searching in a loop according to the process number mapping relationship table in step 2, a loop search is performed from left to right and from top to bottom to find the element whose current process number is equal to the unbinding process number.

[0114] It should be noted that Figure 7 and Figure 8 In the above, i refers to the number of processes that can be bound to a fixed core, j refers to the number of fixed cores, and in a specific embodiment, the value of i is 0-9, and the value of j is 1-4.

[0115] An embodiment of a simulator process monitoring method is described in detail above. Based on the simulator process monitoring method described in the above embodiment, an embodiment of the present invention further provides a simulator process monitoring system corresponding to the method.

[0116] Fig. 9 It is a schematic block diagram of the structure of a simulator process monitoring system provided by an embodiment of the present invention. In this embodiment, the simulator process monitoring system 900 can be divided into multiple functional modules according to the functions it performs. The module referred to in the present invention refers to a series of computer program segments that can be executed by at least one processor and can complete fixed functions, which are stored in a memory.

[0117] CPU core division module 910: divides the isolated CPU core into business cores and fixed cores, and all fixed cores constitute a recycling pool; the business cores are bound one-to-one to the simulator process, and the fixed cores are bound one-to-many to the simulator process.

[0118] New simulator process binding core module 920: bind the new simulator process to the core, including when there is a new simulator process, if there are idle business cores, then bind the new simulator process to one of the idle business cores; if there are no idle business cores, screen the target business cores, transfer the simulator process on the target business core to the fixed core, and then bind the new simulator process to one of the target business cores; if there is no target business core, exit the binding of the new simulator process; wherein, the target business core refers to a business core whose CPU usage of the simulator process bound to it is less than the usage threshold.

[0119] Simulator process transfer and core binding module 930: performs simulator process transfer and core binding, including periodically transferring and binding the simulator process on the target business core to a fixed core when there is no new simulator process, and transferring and binding the simulator process on the target fixed core to an idle business core; wherein the target fixed core refers to a fixed core whose CPU usage of the simulator process bound to it is greater than or equal to the usage threshold.

[0120] In an optional implementation, the newly added simulator process core binding module 920 is specifically used to: obtain the process number of the newly added simulator process and save it to the newly added simulator process list; obtain the status of each business core and count the number of idle business cores; determine whether the number of idle business cores is greater than or equal to 1; if so, bind the newly added simulator process to one of the idle business cores, and record the status of the bound business core as occupied, and delete the newly added simulator process from the newly added simulator process list; if not, filter the target business core, transfer the simulator process on the target business core to the fixed core, and then bind the newly added simulator process to one of the target business cores.

[0121] In an optional implementation, the target business core is screened, the simulator process on the target business core is transferred to the fixed core, and then the newly added simulator process is bound to one of the target business cores. If the target business core does not exist, the newly added simulator process binding is exited, specifically including: Step 1, obtain all simulator process information, and filter out the process ID and CPU usage of all currently running simulator processes; Step 2, saving the filtered simulator process information into a first file; Step 3, query whether there is the next simulator process information in the first file, if yes, execute step 4, otherwise execute step 8; Step 4, determine whether the CPU usage of the next simulator process is less than the usage threshold, if so, execute step 5, otherwise return to step 3; Step 5, determine whether the CPU core bound to the next simulator process is a business core, if so, execute step 6, otherwise return to step 3; Step 6, recycle the next simulator process to the recycling pool; Step 7, determine whether the recycling pool is successfully recycled, if so, return to step 2, otherwise exit abnormally and delete the newly added simulator process from the newly added simulator process list; Step 8: Count the number of idle service cores; Step 9, determine whether the number of idle business cores is greater than or equal to 1. If so, bind the newly added simulator process to one of the idle business cores, and record the status of the bound business core as occupied. At the same time, delete the newly added simulator process from the list of newly added simulator processes; otherwise, exit abnormally and delete the newly added simulator process from the list of newly added simulator processes.

[0122] In an optional embodiment, the system 900 also includes a mapping table construction module 940, which is used to construct a process number mapping relationship table, specifically including: constructing a data structure to record the process number information of the simulator process bound to each fixed core, to realize the construction of the process number mapping relationship table; after the terminal where the simulator process is located is restarted, the recycling pool data is initialized, and all process numbers in the process number mapping relationship table are cleared.

[0123] In an optional implementation, the simulator process transfer core binding module 930 is specifically configured to perform the following steps: Step 1, get the new simulator process list; Step 2, determine whether the newly added simulator process list is empty, if not, wait for a preset time and return to step 1, if yes, obtain the process number information that is not 0 in the process number mapping table, and record it in the second file; Step 3, determine whether there is the next process number information in the second file, if not, wait for a preset time and return to step 1, if yes, execute step 4; Step 4, query the CPU usage of the simulator process of the next process number information, and determine whether the CPU usage is greater than or equal to the usage threshold, if not, return to step 3, if yes, execute step 5; Step 5, query the fixed core information bound to the simulator process of the next process number information; Step 6: Obtain the number of idle service cores; Step 7, determine whether the number of idle service cores is greater than or equal to 1, if so, execute step 8, otherwise execute step 10; Step 8, releasing the simulator process of the next process number information from the recycling pool; Step 9, determine whether the release of the recycling pool is successful, if so, return to step 3, otherwise wait for a preset time and return to step 1; Step 10, obtain all simulator process information, and filter out the process ID and CPU usage of all currently running simulator processes; Step 11, saving the filtered simulator process information into a third file; Step 12, query whether there is a next simulator process information in the third file, if yes, execute step 13, otherwise execute step 17; Step 13, determine whether the CPU usage of the next simulator process is less than the usage threshold, if so, only execute step 14, otherwise return to step 12; Step 14, determine whether the CPU core bound to the next simulator process is a business core, if so, execute step 15, otherwise return to step 12; Step 15, recycle the next simulator process to the recycling pool; Step 16, determine whether the recycling pool is successfully recycled, if so, return to step 12, otherwise exit abnormally and execute step 17; Step 17, counting the number of idle service cores; Step 18, determine whether the number of idle service cores is greater than or equal to 1, if so, execute step 8, otherwise wait for a preset time and return to step 1.

[0124] In an optional implementation, the system 900 further includes a process recycling module 950, which is used to recycle the simulator process to a recycling pool, specifically including: Step 1, obtain the simulator process information that needs to be recycled, and set the recycling flag to 0; Step 2: Loop through the process number mapping table to find the first element with process number 0, record it as the target element, and execute step 3; if no element with process number 0 is found, do not set it; 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 mark, if the recycling mark is 1, record the recycling success, if the recycling mark is 0, record the recycling failure.

[0125] In an optional implementation, the system 900 further includes a process release module 960, which releases the simulator process from the recycling pool, specifically including: Step 1, obtain the simulator process information and idle service core number to be released, and set the release flag to 0; Step 2: Search the process number mapping table in a loop to find the element corresponding to the process number of the simulator process to be released, record it as the target element, and execute step 3; if the element corresponding to the process number of the simulator process to be released is not found, no setting is made; Step 3: Bind the simulator process to be released to the idle business core, record the business core status as occupied, and 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 the release success, if the release flag is 0, record the release failure.

[0126] The simulator process monitoring system of this embodiment is used to implement the aforementioned simulator process monitoring method, so the specific implementation method of the system can be seen in the embodiment part of the simulator process monitoring method in the previous text. Therefore, its specific implementation method can refer to the description of the corresponding each part of the embodiment, and will not be introduced in detail here.

[0127] In addition, since the simulator process monitoring system of this embodiment is used to implement the aforementioned simulator process monitoring method, its function corresponds to that of the aforementioned method and will not be described in detail here.

[0128] Fig.10 A schematic diagram of the structure 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 implementing the simulator process monitoring program stored in the memory 1020: (1) Steps for partitioning isolated CPU cores; The isolated CPU is divided into business cores and fixed cores, and all fixed cores form a recycling pool. Business cores are bound to simulator processes one-to-one, and fixed cores are bound to simulator processes one-to-many. (2) Added the steps of binding the simulator process to the core; When a new simulator process is added, if there are idle business cores, the new simulator process will be bound to one of the idle business cores. If there are no idle business cores, the target business cores will be screened, and the simulator process on the target business core will be transferred to the fixed core, and then the new simulator process will be bound to one of the target business cores. If there is no target business core, the binding of the new simulator process will be exited; wherein, the target business core refers to the business core whose CPU usage of the simulator process bound to it is less than the usage threshold; (3) Steps for transferring the simulator process to bind the core; When there is no new simulator process, the simulator process on the target business core is periodically transferred and bound to the fixed core, and the simulator process on the target fixed core is transferred and bound to the idle business core; wherein the target fixed core refers to a fixed core whose CPU usage of the simulator process bound to it is greater than or equal to the usage threshold.

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

[0130] The computer storage medium stores a simulator process monitoring program, and when the simulator process monitoring program is executed by the processor, the following steps are implemented: (1) Steps for partitioning isolated CPU cores; The isolated CPU is divided into business cores and fixed cores, and all fixed cores form a recycling pool. Business cores are bound to simulator processes one-to-one, and fixed cores are bound to simulator processes one-to-many. (2) Added the steps of binding the simulator process to the core; When a new simulator process is added, if there are idle business cores, the new simulator process will be bound to one of the idle business cores. If there are no idle business cores, the target business cores will be screened, and the simulator process on the target business core will be transferred to the fixed core, and then the new simulator process will be bound to one of the target business cores. If there is no target business core, the binding of the new simulator process will be exited; wherein, the target business core refers to the business core whose CPU usage of the simulator process bound to it is less than the usage threshold; (3) Steps for transferring the simulator process to bind the core; When there is no new simulator process, the simulator process on the target business core is periodically transferred and bound to the fixed core, and the simulator process on the target fixed core is transferred and bound to the idle business core; wherein the target fixed core refers to a fixed core whose CPU usage of the simulator process bound to it is greater than or equal to the usage threshold.

[0131] The above disclosure is only a preferred embodiment of the present invention, but the present invention is not limited thereto. Any non-creative changes that can be thought of by a person skilled in the art, as well as several improvements and modifications made without departing from the principle of the present invention, should fall within the protection scope of the present invention.

Claims

1. A simulator process monitoring method, characterized in that: The following steps are involved: (1) Steps for partitioning isolated CPU cores; The isolated CPU is divided into business cores and fixed cores, and all fixed cores form a recycling pool. Business cores are bound to simulator processes one-to-one, and fixed cores are bound to simulator processes one-to-many. (2) Added the steps of binding the simulator process to the core; When a new simulator process is added, if there are idle business cores, the new simulator process will be bound to one of the idle business cores. If there are no idle business cores, the target business cores will be screened, and the simulator process on the target business core will be transferred to the fixed core, and then the new simulator process will be bound to one of the target business cores. If there is no target business core, the binding of the new simulator process will be exited; wherein, the target business core refers to the business core whose CPU usage of the simulator process bound to it is less than the usage threshold; (3) Steps for transferring the simulator process to bind the core; When there is no new simulator process, the simulator process on the target business core is periodically transferred and bound to the fixed core, and the simulator process on the target fixed core is transferred and bound to the idle business core; wherein the target fixed core refers to a fixed core whose CPU usage of the simulator process bound to it is greater than or equal to the usage threshold.

2. The simulator process monitoring method according to claim 1, characterized in that: If there are idle business cores, the newly added simulator process is bound to one of the idle business cores. If there are no idle business cores, the target business core is selected, the simulator process on the target business core is transferred to the fixed core, and the newly added simulator process is bound to one of the target business cores, including: Get the process ID of the newly added simulator process and save it to the newly added simulator process list; Obtain the status of each business core and count the number of idle business cores; Determine whether the number of idle business cores is greater than or equal to 1; If yes, the newly added simulator process is bound to one of the idle business cores, and the state of the bound business core is recorded as occupied, and the newly added simulator process is deleted from the newly added simulator process list; If not, the target business core is selected, the simulator process on the target business core is transferred to the fixed core, and then the newly added simulator process is bound to one of the target business cores.

3. The simulator process monitoring method according to claim 2, characterized in that: Filter the target business core, transfer the simulator process on the target business core to the fixed core, and then bind the newly added simulator process to one of the target business cores. If the target business core does not exist, exit the newly added simulator process binding, including: Step 1, obtain all simulator process information, and filter out the process ID and CPU usage of all currently running simulator processes; Step 2, saving the filtered simulator process information into a first file; Step 3, query whether there is the next simulator process information in the first file, if yes, execute step 4, otherwise execute step 8; Step 4, determine whether the CPU usage of the next simulator process is less than the usage threshold, if so, execute step 5, otherwise return to step 3; Step 5, determine whether the CPU core bound to the next simulator process is a business core, if so, execute step 6, otherwise return to step 3; Step 6, recycle the next simulator process to the recycling pool; Step 7, determine whether the recycling pool is successfully recycled, if so, return to step 2, otherwise exit abnormally and delete the newly added simulator process from the newly added simulator process list; Step 8: Count the number of idle service cores; Step 9, determine whether the number of idle business cores is greater than or equal to 1. If so, bind the newly added simulator process to one of the idle business cores, and record the status of the bound business core as occupied. At the same time, delete the newly added simulator process from the list of newly added simulator processes; otherwise, exit abnormally and delete the newly added simulator process from the list of newly added simulator processes.

4. The simulator process monitoring method according to claim 3, characterized in that: The method also includes the step of constructing a process number mapping relationship table, specifically including: Construct a data structure to record the process number information of the simulator process bound to each fixed core and implement the process number mapping relationship table construction; After the terminal where the simulator process is located is restarted, the recycling pool data is initialized and all process numbers in the process number mapping table are cleared.

5. The simulator process monitoring method according to claim 4, characterized in that: When there is no new simulator process, the simulator process on the target business core is regularly transferred and bound to the fixed core, and the simulator process on the target fixed core is transferred and bound to the idle business core, specifically including: Step 1, get the new simulator process list; Step 2, determine whether the newly added simulator process list is empty, if not, wait for a preset time and return to step 1, if yes, obtain the process number information that is not 0 in the process number mapping table, and record it in the second file; Step 3, determine whether there is the next process number information in the second file, if not, wait for a preset time and return to step 1, if yes, execute step 4; Step 4, query the CPU usage of the simulator process of the next process number information, and determine whether the CPU usage is greater than or equal to the usage threshold, if not, return to step 3, if yes, execute step 5; Step 5, query the fixed core information bound to the simulator process of the next process number information; Step 6: Obtain the number of idle service cores; Step 7, determine whether the number of idle service cores is greater than or equal to 1, if so, execute step 8, otherwise execute step 10; Step 8, releasing the simulator process of the next process number information from the recycling pool; Step 9, determine whether the release of the recycling pool is successful, if so, return to step 3, otherwise wait for a preset time and return to step 1; Step 10, obtain all simulator process information, and filter out the process ID and CPU usage of all currently running simulator processes; Step 11, saving the filtered simulator process information into a third file; Step 12, query whether there is a next simulator process information in the third file, if yes, execute step 13, otherwise execute step 17; Step 13, determine whether the CPU usage of the next simulator process is less than the usage threshold, if so, only execute step 14, otherwise return to step 12; Step 14, determine whether the CPU core bound to the next simulator process is a business core, if so, execute step 15, otherwise return to step 12; Step 15, recycle the next simulator process to the recycling pool; Step 16, determine whether the recycling pool is successfully recycled, if so, return to step 12, otherwise exit abnormally and execute step 17; Step 17, counting the number of idle service cores; Step 18, determine whether the number of idle service cores is greater than or equal to 1, if so, execute step 8, otherwise wait for a preset time and return to step 1.

6. The simulator process monitoring method according to claim 5, characterized in that: Recycle the simulator process to the recycling pool, including: Step 1, obtain the simulator process information that needs to be recycled, and set the recycling flag to 0; Step 2: Loop through the process number mapping table to find the first element with process number 0, record it as the target element, and execute step 3; if no element with process number 0 is found, do not set it; 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 mark, if the recycling mark is 1, record the recycling success, if the recycling mark is 0, record the recycling failure.

7. The simulator process monitoring method according to claim 5, characterized in that: Release the simulator process from the recycling pool, including: Step 1, obtain the simulator process information and idle service core number to be released, and set the release flag to 0; Step 2: Search the process number mapping table in a loop to find the element corresponding to the process number of the simulator process to be released, record it as the target element, and execute step 3; if the element corresponding to the process number of the simulator process to be released is not found, no setting is made; Step 3: Bind the simulator process to be released to the idle business core, record the business core status as occupied, and 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 the release success, if the release flag is 0, record the release failure.

8. A simulator process monitoring system, characterized in that: include, CPU core division module: divides the isolated CPU cores into service cores and fixed cores. All fixed cores form a recycling pool. The business core is bound to the simulator process one-to-one, and the fixed core is bound to the simulator process one-to-many; New simulator process binding core module: bind the new simulator process to the core, including when there is a new simulator process, if there is an idle business core, bind the new simulator process to one of the idle business cores, if there is no idle business core, filter the target business core, transfer the simulator process on the target business core to the fixed core, and then bind the new simulator process to one of the target business cores, if there is no target business core, exit the binding of the new simulator process; where the target business core refers to the business core whose CPU usage of the simulator process bound to it is less than the usage threshold; Simulator process transfer and core binding module: performs simulator process transfer and core binding, including periodically transferring and binding the simulator process on the target business core to a fixed core when there is no new simulator process, and transferring and binding the simulator process on the target fixed core to an idle business core; wherein, the target fixed core refers to a fixed core whose CPU usage of the simulator process bound to it is greater than or equal to the usage threshold.

9. A terminal, characterized in that: include: A memory, used for storing a simulator process monitoring program; A processor is used 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 a simulator process monitoring program, which, when executed by a processor, implements the steps of the simulator process monitoring method according to any one of claims 1 to 7.

Images