Virtual processor scheduling method and device, equipment and medium

Abstract

The embodiment of the invention provides a virtual processor scheduling method and device, equipment and a medium, which are applied to the technical field of virtualization, and the method comprises the following steps: creating a running queue comprising a plurality of virtual processors, and determining a weight parameter of each virtual processor; at the beginning of each scheduling cycle, distributing an initial credit value for each virtual processor; according to the weight parameter, determining a first target virtual processor from the operation queue, and performing credit value supplement on the first target virtual processor based on a preset shared credit pool; determining a current state of the plurality of virtual processors after credit value supplementation; and determining a second target virtual processor from the running queue according to the current state and the weight parameter, and calling the second target virtual processor to execute a task. Through the embodiment of the invention, the optimization of the virtual machine scheduling is realized, the complexity of the virtual machine scheduling is reduced, and the real-time performance is improved.

Description

Technical Field

[0001] The present invention relates to the field of virtualization technology, and in particular to a scheduling method, device, equipment and medium for a virtual processor. Background Art

[0002] When virtualization technology is applied in a dual-system architecture consisting of a general purpose operating system (GPOS) and a real-time operating system (RTOS), a general hypervisor is usually used to manage virtual machines, such as RT-Xen (an open source virtual machine hypervisor). Its implementation process starts with initialization, adopts a fixed priority scheduling strategy, loads and configures four server scheduling strategies, such as deferrable servers, periodic servers, polling servers, and sporadic servers, and then allocates a virtual processor (Virtual Central Processing Unit, VCPU) to each virtual machine, sets its budget, cycle, priority and other parameters, and then implements different scheduling logics according to the selected scheduling strategy, thereby ensuring its real-time performance.

[0003] Although the above method has advantages in real-time performance, it involves four server scheduling algorithms, each of which has its own complex supplement and scheduling rules, which increases the complexity of the system and has high development and maintenance costs. The high complexity may limit its use in certain application scenarios. Summary of the invention

[0004] In view of the above problems, a method, apparatus, device and medium for scheduling a virtual processor is proposed to overcome the above problems or at least partially solve the above problems, including:

[0005] A virtual processor scheduling method, the method comprising:

[0006] Creating a run queue including multiple virtual processors and determining a weight parameter for each virtual processor;

[0007] At the beginning of each scheduling cycle, an initial credit value is assigned to each virtual processor;

[0008] Determine a first target virtual processor from the run queue according to the weight parameter, and supplement the credit value of the first target virtual processor based on a preset shared credit pool;

[0009] determining a current state of the plurality of virtual processors after credit replenishment;

[0010] According to the current state and the weight parameter, a second target virtual processor is determined from the run queue, and the second target virtual processor is called to execute the task.

[0011] Optionally, determining the second target virtual processor from the run queue according to the current state and the weight parameter includes:

[0012] Determining a candidate virtual processor from the run queue according to the current state;

[0013] A second target virtual processor is determined from the candidate virtual processors according to the weight parameter.

[0014] Optionally, determining a candidate virtual processor from the run queue according to the current state includes:

[0015] In the case that there is a virtual processor whose current state is a first state in the run queue, the virtual processor whose current state is a first state is determined as a candidate virtual processor from the run queue; the first state is a state when the virtual processor is performing an input operation or an output operation.

[0016] Optionally, it also includes:

[0017] In the case that there is no virtual processor whose current state is the first state in the running queue but there is a virtual processor whose current state is the second state, the virtual processor whose current state is the second state is determined as a candidate virtual processor from the running queue; the second state is a state when the virtual processor has remaining available credit value.

[0018] Optionally, it also includes:

[0019] In the case that there is no virtual processor whose current state is the first state or the second state in the running queue but there is a virtual processor whose current state is the third state, the virtual processor whose current state is the third state is determined as a candidate virtual processor from the running queue; the third state is a state when the virtual processor has no remaining available credit value.

[0020] Optionally, the plurality of virtual processors include an idle virtual processor, and the idle virtual processor is arranged at the end of the run queue, further comprising:

[0021] In the case that there is no virtual processor whose current state is the first state, the second state, or the third state in the run queue, the idle virtual processor is determined as a candidate virtual processor.

[0022] Optionally, determining the second target virtual processor from the candidate virtual processors according to the weight parameter includes:

[0023] The candidate virtual processor with the highest weight parameter is determined as the second target virtual processor.

[0024] Optionally, before calling the second target virtual processor to execute the task, the method further includes:

[0025] removing the second target virtual machine from the run queue;

[0026] After calling the second target virtual processor to execute the task, the method further includes:

[0027] After the execution of the task is completed, the second target virtual machine is inserted into the run queue.

[0028] Optionally, after calling the second target virtual processor to execute the task, the method further includes:

[0029] When the credit value of the second target virtual processor is exhausted during the process of calling the second target virtual processor to execute the task, the current state of the second target virtual processor is updated to a third state; the third state is the state when the virtual processor has no remaining available credit value.

[0030] Optionally, after calling the second target virtual processor to execute the task, the method further includes:

[0031] The virtual processors in the running queue that have no tasks to be executed are migrated to a preset waiting queue.

[0032] Optionally, it also includes:

[0033] The credit values ​​of the virtual processors in the waiting queue are returned to the shared credit pool.

[0034] Optionally, determining the first target virtual processor from the run queue according to the weight parameter includes: determining the virtual processor with the highest weight parameter from the run queue as the first target virtual processor.

[0035] Optionally, the supplementing the credit value of the first target virtual processor based on a preset shared credit pool includes:

[0036] When the credit value of the first target virtual processor does not reach an upper limit, the credit value of the first target virtual processor is supplemented based on a preset shared credit pool until the credit value of the first target virtual processor reaches an upper limit or the shared credit pool is insufficient.

[0037] Optionally, the current state includes any one of a first state, a second state, and a third state; wherein the first state is a state when the virtual processor is performing an input operation or an output operation, the second state is a state when the virtual processor has a remaining available credit value, and the third state is a state when the virtual processor has no remaining available credit value.

[0038] Optionally, before allocating an initial credit value to each virtual processor at the beginning of each scheduling cycle, the method further includes:

[0039] The maximum running time of each virtual processor in a scheduling cycle is determined to limit the running time of the virtual processor when the virtual processor is scheduled.

[0040] Optionally, the virtual processor runs in a device with a dual system architecture, and a general operating system and a real-time operating system are deployed under the dual system architecture.

[0041] A virtual processor scheduling device, the device comprising:

[0042] An initialization module, used to create a run queue containing multiple virtual processors and determine a weight parameter of each virtual processor;

[0043] A credit allocation module, used to allocate an initial credit value to each virtual processor at the beginning of each scheduling cycle;

[0044] a credit supplement module, configured to determine a first target virtual processor from the run queue according to the weight parameter, and supplement the credit value of the first target virtual processor based on a preset shared credit pool;

[0045] a current state determination module, configured to determine the current states of the plurality of virtual processors after the credit value is replenished;

[0046] The virtual processor calling module is used to determine a second target virtual processor from the run queue according to the current state and the weight parameter, and call the second target virtual processor to execute the task.

[0047] An electronic device comprises a processor, a memory and a computer program stored in the memory and capable of running on the processor, wherein the computer program implements the method described above when executed by the processor.

[0048] A computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method described above is implemented.

[0049] A computer program product comprises a computer program, wherein when the computer program is executed by a processor, the computer program implements the method as described above.

[0050] The embodiments of the present invention have the following advantages:

[0051] In an embodiment of the present invention, a running queue including multiple virtual processors is created, and a weight parameter of each virtual processor is determined. At the beginning of each scheduling cycle, an initial credit value is allocated to each virtual processor. According to the weight parameter, a first target virtual processor is determined from the running queue, and the credit value of the first target virtual processor is supplemented based on a preset shared credit pool. The current state of the multiple virtual processors after the credit value supplement is determined, and according to the current state and the weight parameter, a second target virtual processor is determined from the running queue, and the second target virtual processor is called to execute the task, thereby optimizing the virtual machine scheduling, reducing the complexity of the virtual machine scheduling, and improving the real-time performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the technical solution of the present invention, the accompanying drawings required for use in the description of the present invention will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative labor.

[0053] Figure 1 is a flowchart of steps of a virtual processor scheduling method provided by some embodiments of the present invention;

[0054] Figure 2 is a flowchart of steps of another virtual processor scheduling method provided by some embodiments of the present invention;

[0055] Figure 3 is a flowchart of steps of another virtual processor scheduling method provided by some embodiments of the present invention;

[0056] Figure 4 is a flowchart of steps of another virtual processor scheduling method provided by some embodiments of the present invention;

[0057] Figure 5 is a structural block diagram of a scheduling device for a virtual processor provided by some embodiments of the present invention;

[0058] Figure 6 is a structural block diagram of an electronic device provided by some embodiments of the present invention;

[0059] Figure 7 is a structural block diagram of a storage medium provided by some embodiments of the present invention;

[0060] Figure 8 It is a structural block diagram of a program product provided by some embodiments of the present invention. DETAILED DESCRIPTION

[0061] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0062] As semiconductor technology advances, computing devices are becoming smaller and faster, which in turn has spurred the development of "smart" lab equipment that can control complex networks of devices and process large amounts of data quickly and reliably. As more functionality is pushed onto lab equipment and personal computers, the complexity required to manage external resources, events, and information grows.

[0063] In order to effectively develop advanced applications (such as web browsers or media players), a general-purpose operating system (GPOS) with advanced functions is usually indispensable. Most GPOS cannot meet the strict requirements of real-time control systems in terms of security, reliability, and determinism. For example, security vulnerabilities are constantly being discovered in GPOS such as Windows and Linux.

[0064] In some cases, only a real-time operating system (RTOS) can meet the time and resource constraints of such systems. A real-time system is one whose correctness involves the logical correctness and timeliness of the output. It must meet response time constraints, otherwise it may face serious consequences such as system failure.

[0065] In order to reduce product costs, real-time control systems and advanced information systems are integrated on a single platform. Since many applications require the integration of components of different criticality levels (criticality level usually refers to the level of protection of system components against failures) on the same physical platform to meet requirements related to cost, space, weight, and power consumption, such systems are called mixed-criticality systems (MCS). For example, the integration of real-time systems and non-real-time interactive systems on the same platform is considered a special dual-criticality system (DCS).

[0066] RTOS is mainly used in server management chips (server management chips are usually integrated on the server motherboard and provide management functions independent of the host operating system, such as power control, hardware monitoring, logging, and remote control) to handle tasks that require high real-time and reliability. For example, monitoring the hardware status of the server, responding to hardware failures, and performing emergency power management operations. These tasks require the system to be able to respond within strict time limits to ensure the stable operation of the server and data security. RTOS has a deterministic scheduling mechanism and low latency, which can meet these high real-time requirements.

[0067] GPOS is used to provide richer management functions and higher flexibility. With powerful network, storage and user interface support, GPOS can easily implement complex functions such as remote management, firmware update and log analysis. Since GPOS supports a wide range of applications and tools, developers can more easily expand and customize the functions of server management chips.

[0068] By designing a dual-system architecture, tasks of different natures can be separated to ensure that critical real-time tasks are not interfered with by non-real-time tasks. For example, RTOS is responsible for critical hardware monitoring and emergency management, while GPOS handles less urgent but more complex management tasks. This task separation can optimize the use of system resources and improve the efficiency and reliability of the overall system.

[0069] By using a dual system architecture, the server management chip can achieve higher security and fault tolerance. If the GPOS fails, the RTOS can still continue to perform key monitoring and management tasks to ensure that the basic management functions of the server are not affected. This design improves the reliability of the server management chip and ensures that the normal operation of the server can be maintained in various situations.

[0070] As virtualization becomes more and more attractive in the industry, because it promises to integrate, manage, and reuse heterogeneous software components with mixed criticality levels on a shared hardware platform in a flexible way while obtaining isolation guarantees, some virtualization solutions have been proposed for GPOS and RTOS to run in parallel, such as the hybrid kernel approach, which executes both GPOS and RTOS at a privileged level and directly accesses the hardware.

[0071] Although this method is low-cost, due to the lack of hardware protection, the RTOS may be threatened by malicious attacks or improper behavior of the GPOS. For example, if the GPOS loses control with interrupts disabled, the RTOS will not be able to recover. In addition, the GPOS may also access the memory allocated to the RTOS, resulting in data leakage or theft of sensitive information.

[0072] When virtualization technology is applied in a dual-system architecture consisting of a general-purpose operating system and a real-time operating system, a general-purpose hypervisor is usually used to manage virtual machines. The hypervisor (a hypervisor is a software layer that abstracts hardware resources and is designed to run different and isolated application environments, called virtual machines or clients, on the same physical machine) provides strong isolation between multiple client operating systems by executing under lower permissions.

[0073] For example, general hypervisors mainly include Xen (an open source virtual machine monitor) and KVM (Kernel-Based Virtual Machine, a virtualization technology based on the Linux kernel). Among them, Xen provides paravirtualization technology and is a hypervisor for bare metal. KVM is a hardware-assisted virtualization solution that utilizes the hardware extensions provided by modern CPUs.

[0074] KVM is a hypervisor for host systems that needs to be executed on the Linux kernel. They are a good choice when there are cloud computing related requirements (such as virtual machine migration, etc.). For real-time requirements, it can be done by patching or redesigning specific components of the CPU.

[0075] Xen's main approach is to optimize the scheduling algorithm of the virtual CPU and improve interrupt handling. By default, Xen adopts credit scheduling. In addition to coordinating the CPU sharing of each domain, the scheduler also needs to balance the workload. For real-time requirements, this can be done through patches or redesigning specific components of the CPU.

[0076] In Xen, RT-Xen (an open source virtual machine hypervisor) can be used to meet the real-time requirements when applying virtualization technology in a dual-system architecture consisting of a general-purpose operating system and a real-time operating system. Its implementation process starts with initialization, adopts a fixed priority scheduling strategy, loads and configures four server scheduling strategies, such as deferrable servers, periodic servers, polling servers, and sporadic servers, and then allocates a virtual processor (Virtual Central Processing Unit, VCPU) to each virtual machine, sets its budget, cycle, priority and other parameters, and then implements different scheduling logics according to the selected scheduling strategy, thereby ensuring its real-time performance.

[0077] Although the above method has advantages in real-time performance, it involves four server scheduling algorithms, each of which has its own complex supplement and scheduling rules, which increases the complexity of the system and has high development and maintenance costs. The high complexity may limit its use in certain application scenarios.

[0078] In order to solve the problem that solutions such as Xen virtualization are insufficient in meeting the requirements of real-time tasks of real-time systems, and the existing solutions such as rt-Xen are too complex, an object of the present invention is to provide a scheduling strategy of shared credits. The scheduling strategy allows all virtual CPUs (VCPUs) to share and dynamically allocate credits in each scheduling cycle by establishing a global shared credit pool.

[0079] Through the embodiments of the present invention, it is possible to improve resource utilization, enhance system flexibility, adapt to various load conditions, and ensure the scheduling requirements of real-time tasks. If a CPU with task processing requirements cannot obtain credit in time, during the scheduling process, according to the settings of Xen itself, even a CPU in the OVER (end) state has a chance to be scheduled by the scheduling strategy, so as not to rely entirely on credit.

[0080] Specifically, the embodiment of the present invention proposes to establish a shared credit pool based on Xen's credit scheduling, store the remaining credits after each task is executed in the shared credit pool, and allocate credits to the VCPU with the highest weight in RunQ (RunQueue) at the beginning of each scheduling cycle. Such an allocation scheme can effectively allocate credits to VCPUs with high weights and possible credits, so that VCPUs with high weights can effectively complete the assigned tasks before the deadline, meeting the real-time performance requirements of virtualization software for real-time systems.

[0081] Moreover, based on the credit scheduling of Xen proposed in the embodiment of the present invention, a shared credit pool is established, and its shared credit allocation mechanism is only allocated to the VCPU with the highest weight and tasks to be run at the beginning of each cycle. This greatly improves the responsiveness of the real-time system.

[0082] Through the embodiments of the present invention, it can be ensured that high-weight VCPUs or tasks that need to be processed urgently can obtain resources in a timely manner, thereby improving the overall system performance and the response speed of real-time tasks. Through the proposed shared credit scheduling method, the remaining credits of VCPUs without tasks can be centrally managed to simplify the scheduling mechanism, and complex server task management mechanisms such as delayable servers, periodic servers, polling servers, and sporadic servers are no longer used.

[0083] The present invention will be further described below in conjunction with the accompanying drawings:

[0084] Reference Figure 1, showing a step flow chart of a virtual processor scheduling method provided by some embodiments of the present invention, the virtual processor may be a VCPU, and the virtual processor runs in a device with a dual-system architecture, in which a general-purpose operating system (GPOS) and a real-time operating system (RTOS) are deployed, that is, the GPOS and RTOS run in parallel in the same device.

[0085] like Figure 2 The embodiment of the present invention includes: system initialization, scheduling cycle start, credit allocation, credit replenishment, scheduling VCPU, updating status and queue, returning credit, and starting the next scheduling cycle.

[0086] Specifically, the following steps may be included:

[0087] Step 101: Create a run queue including multiple virtual processors, and determine a weight parameter of each virtual processor.

[0088] In some embodiments of the present invention, before allocating an initial credit value to each virtual processor at the beginning of each scheduling cycle, the method further includes:

[0089] The maximum running time of each virtual processor in a scheduling cycle is determined to limit the running time of the virtual processor when the virtual processor is scheduled.

[0090] In some examples, the processor is a CPU and the virtual processor is a VCPU.

[0091] The system initialization step includes creating queues and initializing parameters. Specifically, when the system starts, a run queue (RunQ) is initialized on each physical central processing unit (PCPU), which includes all runnable VCPUs and an IDLE VCPU (i.e., an idle virtual processor), and the IDLE VCPU is at the end of the RunQ queue.

[0092] In some examples, two queues, RdyQ (Ready Queue) and RepQ (Repair Queue), may be created during initialization.

[0093] In actual applications, each VCPU initializes two parameters: weight and cap. The weight determines the relative priority of the VCPU in scheduling, and the cap limits the maximum running time of the VCPU in a cycle, and determines the maximum running time of each virtual processor in a scheduling cycle to limit the running time of the virtual processor when the virtual processor is scheduled.

[0094] Step 102: at the beginning of each scheduling cycle, an initial credit value is allocated to each virtual processor.

[0095] The credit allocation step is after the system is initialized, including allocating initial credits to the VCPUs according to their weights at the beginning of each scheduling cycle (e.g., 30ms). The VCPU consumes credits during operation, and enters the OVER state (the third state below) after the credits are used up, which means that the VCPU needs to wait for the next accounting cycle or the shared credit pool to replenish its credits before it can allocate credits again.

[0096] In some examples, the weight of the VCPU can be determined by the attribute information of the task corresponding to the VCPU. In actual applications, a corresponding VCPU can be assigned to the task to be executed. That is to say, each VCPU has a corresponding task. The weight of the VCPU can be determined based on the attribute information of the task corresponding to the VCPU, and then an initial credit value is assigned to it based on the weight for scheduling (scheduling of the VCPU can actually be understood as scheduling of the task corresponding to the VCPU).

[0097] For example, the attribute information may be the latest execution time of the task. The later the latest execution time is, the smaller the weight is, and the earlier the latest execution time is, the larger the weight is.

[0098] Step 103: Determine a first target virtual processor from the run queue according to the weight parameter, and supplement the credit value of the first target virtual processor based on a preset shared credit pool.

[0099] In some embodiments of the present invention, determining the first target virtual processor from the run queue according to the weight parameter includes: determining the virtual processor with the highest weight parameter from the run queue as the first target virtual processor.

[0100] In some embodiments of the present invention, the step of supplementing the credit value of the first target virtual processor based on a preset shared credit pool includes:

[0101] When the credit value of the first target virtual processor does not reach an upper limit, the credit value of the first target virtual processor is supplemented based on a preset shared credit pool until the credit value of the first target virtual processor reaches an upper limit or the shared credit pool is insufficient.

[0102] The credit replenishment step is completed after the credit allocation step, such as Figure 3 , as follows:

[0103] Calculate the VCPU with the highest weight in the RunQ queue (i.e., the first target virtual processor). If its remaining credits have not reached the upper limit, regardless of whether its state is BOOST, UNDER, or OVER, refill its credits until its credits reach the upper limit or the shared credit pool is insufficient. After the credit refill is completed, update the VCPU's status.

[0104] Step 104, determining the current status of the plurality of virtual processors after the credits are replenished.

[0105] In some embodiments of the present invention, the current state includes any one of a first state, a second state, and a third state; wherein the first state is a state when the virtual processor is performing an input operation or an output operation, the second state is a state when the virtual processor has a remaining available credit value, and the third state is a state when the virtual processor has no remaining available credit value.

[0106] Among them, the three states of VCPU in RunQ are:

[0107] BOOST (i.e., the first state), the VCPU is performing I / O operations;

[0108] UNDER (i.e., the second state), the VCPU has remaining credits;

[0109] OVER (i.e., the third state), the VCPU credits have been exhausted.

[0110] Step 105: Determine a second target virtual processor from the run queue according to the current state and the weight parameter, and call the second target virtual processor to execute the task.

[0111] In some embodiments of the present invention, determining the second target virtual processor from the run queue according to the current state and the weight parameter includes:

[0112] According to the current state, a candidate virtual processor is determined from the run queue; and according to the weight parameter, a second target virtual processor is determined from the candidate virtual processors.

[0113] In some embodiments of the present invention, determining a candidate virtual processor from the run queue according to the current state includes:

[0114] In the case that there is a virtual processor whose current state is a first state in the run queue, the virtual processor whose current state is a first state is determined as a candidate virtual processor from the run queue; the first state is a state when the virtual processor is performing an input operation or an output operation.

[0115] In some embodiments of the present invention, it also includes:

[0116] In the case that there is no virtual processor whose current state is the first state in the running queue but there is a virtual processor whose current state is the second state, the virtual processor whose current state is the second state is determined as a candidate virtual processor from the running queue; the second state is a state when the virtual processor has remaining available credit value.

[0117] In some embodiments of the present invention, it also includes:

[0118] In the case that there is no virtual processor whose current state is the first state or the second state in the running queue but there is a virtual processor whose current state is the third state, the virtual processor whose current state is the third state is determined as a candidate virtual processor from the running queue; the third state is a state when the virtual processor has no remaining available credit value.

[0119] In some embodiments of the present invention, the plurality of virtual processors include idle virtual processors, and the idle virtual processors are arranged at the end of the run queue, further comprising:

[0120] In the case that there is no virtual processor whose current state is the first state, the second state, or the third state in the run queue, the idle virtual processor is determined as a candidate virtual processor.

[0121] In some embodiments of the present invention, determining the second target virtual processor from the candidate virtual processors according to the weight parameter includes:

[0122] The candidate virtual processor with the highest weight parameter is determined as the second target virtual processor.

[0123] Scheduling VCPU is done after the credit replenishment step is completed, such as Figure 4 , as follows:

[0124] The scheduler schedules the VCPU with the highest weight in the BOOST state to execute a task of a time slice (e.g. 1ms). If there is no VCPU in the BOOST state, schedule the VCPU in the UNDER state. If there is no schedulable VCPU in the UNDER state, schedule the VCPU in the OVER state. If there is no schedulable VCPU, schedule the IDLE VCPU.

[0125] In some embodiments of the present invention, before calling the second target virtual processor to execute the task, the method further includes: removing the second target virtual processor from the run queue.

[0126] In some embodiments of the present invention, after calling the second target virtual processor to execute the task, the method further includes: inserting the second target virtual processor into the run queue after the execution of the task is completed.

[0127] After the scheduled VCPU is determined, it is taken out of the RunQ queue to prevent other possible physical CPUs from scheduling it. After the scheduled VCPU executes a task for a time slice, it is inserted into the RunQ queue.

[0128] In some embodiments of the present invention, after calling the second target virtual processor to execute the task, it also includes: when the credit value of the second target virtual processor is exhausted in the process of calling the second target virtual processor to execute the task, updating the current state of the second target virtual processor to a third state; the third state is the state when the virtual processor has no remaining available credit value.

[0129] The scheduling queue and VCPU status are updated after the VCPU is scheduled. The VCPU whose credit is exhausted is changed from BOOST or UNDER status to OVER.

[0130] In some embodiments of the present invention, after calling the second target virtual processor to execute the task, the method further includes:

[0131] The virtual processors in the running queue that have no tasks to be executed are migrated to a preset waiting queue.

[0132] In actual applications, for a VCPU that has no tasks to execute in RunQ, a sleep function in Xen is triggered to adjust the VCPU to the RdyQ queue (waiting queue).

[0133] In some embodiments of the present invention, it also includes:

[0134] The credit values ​​of the virtual processors in the waiting queue are returned to the shared credit pool.

[0135] In actual applications, credits are returned after the scheduling queue and VCPU status steps. For VCPUs in the RdyQ queue, if there are any remaining credits, they are returned to the shared credit pool. After that, the next scheduling cycle begins.

[0136] In an embodiment of the present invention, a running queue including multiple virtual processors is created, and a weight parameter of each virtual processor is determined. At the beginning of each scheduling cycle, an initial credit value is allocated to each virtual processor. According to the weight parameter, a first target virtual processor is determined from the running queue, and the credit value of the first target virtual processor is supplemented based on a preset shared credit pool. The current state of the multiple virtual processors after the credit value supplement is determined, and according to the current state and the weight parameter, a second target virtual processor is determined from the running queue, and the second target virtual processor is called to execute the task, thereby optimizing the virtual machine scheduling, reducing the complexity of the virtual machine scheduling, and improving the real-time performance.

[0137] It should be noted that, for the sake of simplicity, the method embodiments are described as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.

[0138] Reference Figure 5 , shows a schematic diagram of the structure of a scheduling device for a virtual processor provided in some embodiments of the present invention, which may specifically include the following modules:

[0139] Initialization module 501, used to create a run queue including multiple virtual processors and determine a weight parameter of each virtual processor;

[0140] A credit allocation module 502, configured to allocate an initial credit value to each virtual processor at the beginning of each scheduling cycle;

[0141] A credit supplement module 503, configured to determine a first target virtual processor from the run queue according to the weight parameter, and supplement the credit value of the first target virtual processor based on a preset shared credit pool;

[0142] A current state determination module 504, configured to determine the current state of the plurality of virtual processors after the credit value is replenished;

[0143] The virtual processor calling module 505 is used to determine a second target virtual processor from the run queue according to the current state and the weight parameter, and call the second target virtual processor to execute the task.

[0144] Optionally, determining the second target virtual processor from the run queue according to the current state and the weight parameter includes:

[0145] Determining a candidate virtual processor from the run queue according to the current state;

[0146] A second target virtual processor is determined from the candidate virtual processors according to the weight parameter.

[0147] Optionally, determining a candidate virtual processor from the run queue according to the current state includes:

[0148] In the case that there is a virtual processor whose current state is a first state in the run queue, the virtual processor whose current state is a first state is determined as a candidate virtual processor from the run queue; the first state is a state when the virtual processor is performing an input operation or an output operation.

[0149] Optionally, it also includes:

[0150] In the case that there is no virtual processor whose current state is the first state in the running queue but there is a virtual processor whose current state is the second state, the virtual processor whose current state is the second state is determined as a candidate virtual processor from the running queue; the second state is a state when the virtual processor has remaining available credit value.

[0151] Optionally, it also includes:

[0152] In the case that there is no virtual processor whose current state is the first state or the second state in the running queue but there is a virtual processor whose current state is the third state, the virtual processor whose current state is the third state is determined as a candidate virtual processor from the running queue; the third state is a state when the virtual processor has no remaining available credit value.

[0153] Optionally, the plurality of virtual processors include an idle virtual processor, and the idle virtual processor is arranged at the end of the run queue, further comprising:

[0154] In the case that there is no virtual processor whose current state is the first state, the second state, or the third state in the run queue, the idle virtual processor is determined as a candidate virtual processor.

[0155] Optionally, determining the second target virtual processor from the candidate virtual processors according to the weight parameter includes:

[0156] The candidate virtual processor with the highest weight parameter is determined as the second target virtual processor.

[0157] Optionally, before calling the second target virtual processor to execute the task, the method further includes:

[0158] removing the second target virtual machine from the run queue;

[0159] After calling the second target virtual processor to execute the task, the method further includes:

[0160] After the execution of the task is completed, the second target virtual machine is inserted into the run queue.

[0161] Optionally, after calling the second target virtual processor to execute the task, the method further includes:

[0162] When the credit value of the second target virtual processor is exhausted during the process of calling the second target virtual processor to execute the task, the current state of the second target virtual processor is updated to a third state; the third state is the state when the virtual processor has no remaining available credit value.

[0163] Optionally, after calling the second target virtual processor to execute the task, the method further includes:

[0164] The virtual processors in the running queue that have no tasks to be executed are migrated to a preset waiting queue.

[0165] Optionally, it also includes:

[0166] The credit values ​​of the virtual processors in the waiting queue are returned to the shared credit pool.

[0167] Optionally, determining the first target virtual processor from the run queue according to the weight parameter includes: determining the virtual processor with the highest weight parameter from the run queue as the first target virtual processor.

[0168] Optionally, the supplementing the credit value of the first target virtual processor based on a preset shared credit pool includes:

[0169] When the credit value of the first target virtual processor does not reach an upper limit, the credit value of the first target virtual processor is supplemented based on a preset shared credit pool until the credit value of the first target virtual processor reaches an upper limit or the shared credit pool is insufficient.

[0170] Optionally, the current state includes any one of a first state, a second state, and a third state; wherein the first state is a state when the virtual processor is performing an input operation or an output operation, the second state is a state when the virtual processor has a remaining available credit value, and the third state is a state when the virtual processor has no remaining available credit value.

[0171] Optionally, before allocating an initial credit value to each virtual processor at the beginning of each scheduling cycle, the method further includes:

[0172] The maximum running time of each virtual processor in a scheduling cycle is determined to limit the running time of the virtual processor when the virtual processor is scheduled.

[0173] Optionally, the virtual processor runs in a device with a dual system architecture, and a general operating system and a real-time operating system are deployed under the dual system architecture.

[0174] In an embodiment of the present invention, a running queue including multiple virtual processors is created, and a weight parameter of each virtual processor is determined. At the beginning of each scheduling cycle, an initial credit value is allocated to each virtual processor. According to the weight parameter, a first target virtual processor is determined from the running queue, and the credit value of the first target virtual processor is supplemented based on a preset shared credit pool. The current state of the multiple virtual processors after the credit value supplement is determined, and according to the current state and the weight parameter, a second target virtual processor is determined from the running queue, and the second target virtual processor is called to execute the task, thereby optimizing the virtual machine scheduling, reducing the complexity of the virtual machine scheduling, and improving the real-time performance.

[0175] Reference Figure 6 , shows an electronic device provided by some embodiments of the present invention, including a processor 601, a memory 602, and a computer program stored in the memory 602 and capable of running on the processor 601, and the above method is implemented when the computer program is executed by the processor.

[0176] Reference Figure 7 , shows a computer-readable storage medium 700 provided in some embodiments of the present invention, on which a computer program is stored, and the computer program implements the above method when executed by a processor.

[0177] Reference Figure 8 , shows a computer program product 800 provided by some embodiments of the present invention, including a computer program, which implements the above method when executed by a processor.

[0178] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0179] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

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

[0181] Those skilled in the art will appreciate that the embodiments of the present invention may be provided as methods, devices, or computer program products. Therefore, the embodiments of the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0182] The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0183] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0184] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0185] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0186] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "including one..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the above elements.

[0187] The above is a detailed introduction to the scheduling method, device, equipment and medium of a virtual processor provided. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. At the same time, for those skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A virtual processor scheduling method, characterized in that: The method comprises: Creating a run queue including multiple virtual processors and determining a weight parameter for each virtual processor; At the beginning of each scheduling cycle, an initial credit value is assigned to each virtual processor; Determine a first target virtual processor from the run queue according to the weight parameter, and supplement the credit value of the first target virtual processor based on a preset shared credit pool; determining a current state of the plurality of virtual processors after credit replenishment; According to the current state and the weight parameter, a second target virtual processor is determined from the run queue, and the second target virtual processor is called to execute the task.

2. The method according to claim 1, characterized in that Determining the second target virtual processor from the run queue according to the current state and the weight parameter includes: Determining a candidate virtual processor from the run queue according to the current state; A second target virtual processor is determined from the candidate virtual processors according to the weight parameter.

3. The method according to claim 2, characterized in that Determining a candidate virtual processor from the run queue according to the current state includes: In the case that there is a virtual processor whose current state is a first state in the run queue, the virtual processor whose current state is a first state is determined as a candidate virtual processor from the run queue; the first state is a state when the virtual processor is performing an input operation or an output operation.

4. The method according to claim 3, characterized in that Also includes: In the case that there is no virtual processor whose current state is the first state in the running queue but there is a virtual processor whose current state is the second state, the virtual processor whose current state is the second state is determined as a candidate virtual processor from the running queue; the second state is a state when the virtual processor has remaining available credit value.

5. The method according to claim 4, characterized in that Also includes: In the case that there is no virtual processor whose current state is the first state or the second state in the running queue but there is a virtual processor whose current state is the third state, the virtual processor whose current state is the third state is determined as a candidate virtual processor from the running queue; the third state is a state when the virtual processor has no remaining available credit value.

6. The method according to claim 5, characterized in that The plurality of virtual processors include an idle virtual processor, and the idle virtual processor is arranged at the end of the run queue, further comprising: In the case that there is no virtual processor whose current state is the first state, the second state, or the third state in the run queue, the idle virtual processor is determined as a candidate virtual processor.

7. The method according to claim 3, characterized in that Determining the second target virtual processor from the candidate virtual processors according to the weight parameter includes: The candidate virtual processor with the highest weight parameter is determined as the second target virtual processor.

8. The method according to any one of claims 1 to 7, characterized in that: Before calling the second target virtual processor to execute the task, the method further includes: removing the second target virtual machine from the run queue; After calling the second target virtual processor to execute the task, the method further includes: After the execution of the task is completed, the second target virtual machine is inserted into the run queue.

9. The method according to any one of claims 1 to 7, characterized in that: After calling the second target virtual processor to execute the task, the method further includes: When the credit value of the second target virtual processor is exhausted during the process of calling the second target virtual processor to execute the task, the current state of the second target virtual processor is updated to a third state; the third state is the state when the virtual processor has no remaining available credit value.

10. The method according to any one of claims 1 to 7, characterized in that: After calling the second target virtual processor to execute the task, the method further includes: The virtual processors in the running queue that have no tasks to be executed are migrated to a preset waiting queue.

11. The method according to claim 10, characterized in that Also includes: The credit values ​​of the virtual processors in the waiting queue are returned to the shared credit pool.

12. The method according to claim 1, characterized in that Determining the first target virtual processor from the run queue according to the weight parameter includes: determining the virtual processor with the highest weight parameter from the run queue as the first target virtual processor.

13. The method according to claim 1, characterized in that The step of supplementing the credit value of the first target virtual processor based on the preset shared credit pool includes: When the credit value of the first target virtual processor does not reach an upper limit, the credit value of the first target virtual processor is supplemented based on a preset shared credit pool until the credit value of the first target virtual processor reaches an upper limit or the shared credit pool is insufficient.

14. The method according to claim 1, characterized in that The current state includes any one of a first state, a second state, and a third state; wherein the first state is a state when the virtual processor is performing an input operation or an output operation, the second state is a state when the virtual processor has a remaining available credit value, and the third state is a state when the virtual processor has no remaining available credit value.

15. The method according to claim 1, characterized in that Before allocating an initial credit value to each virtual processor at the beginning of each scheduling cycle, the method further includes: The maximum running time of each virtual processor in a scheduling cycle is determined to limit the running time of the virtual processor when the virtual processor is scheduled.

16. The method according to claim 1, characterized in that The virtual processor runs in a device with a dual-system architecture, and a general operating system and a real-time operating system are deployed under the dual-system architecture.

17. A virtual processor scheduling device, characterized in that: The device comprises: An initialization module, used to create a run queue containing multiple virtual processors and determine a weight parameter of each virtual processor; A credit allocation module, used to allocate an initial credit value to each virtual processor at the beginning of each scheduling cycle; a credit supplement module, configured to determine a first target virtual processor from the run queue according to the weight parameter, and supplement the credit value of the first target virtual processor based on a preset shared credit pool; a current state determination module, configured to determine the current states of the plurality of virtual processors after the credit value is replenished; The virtual processor calling module is used to determine a second target virtual processor from the run queue according to the current state and the weight parameter, and call the second target virtual processor to execute the task.

18. An electronic device, characterized in that: The method comprises a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program implements the method according to any one of claims 1 to 16 when executed by the processor.

19. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 16 is implemented.

20. A computer program product, characterized in that The invention comprises a computer program which, when executed by a processor, implements the method according to any one of claims 1 to 16.

Images