JP4620097B2 - Virtual computer system and schedule adjustment method in the same system - Google Patents

Description

  The present invention relates to a virtual machine system in which a plurality of guest OSs are executed in a time-sharing manner in a virtual machine execution environment provided by a virtual machine manager operating on a physical machine including a CPU, and in particular, a plurality of guest OSs are time-shared. The present invention relates to a virtual machine system suitable for adjusting a schedule for execution in the system (that is, a schedule for dispatching a guest OS) and a schedule adjustment method in the system.

  In recent years, in computer systems such as personal computers, research and development using virtual machine (VM) technology has been carried out, and commercial application programs for realizing virtual computer systems are actually widely used. It's being used. There is also a virtual machine system that uses a virtual machine support mechanism configured with hardware (HW) for a long time in the mainframe.

  In general, a computer system (physical computer) such as a personal computer includes a CPU (real CPU), various input / output (I / O) devices (real I / O devices), and a memory (real memory) HW (real HW). ). A virtual machine manager (VMM), which is a hypervisor OS (operating system), operates on a physical computer (physical environment) configured with this real HW, and is under the virtual computer execution environment provided by this VMM. Multiple guest OSes operate.

  The VMM manages physical resources such as a real CPU, real I / O device, and real memory, and virtualizes them to construct a virtual machine (VM). In other words, the VMM has a physical resource (HW resource) such as a real CPU, a real I / O device, and a real memory in terms of time and space (area) in a virtual machine, a virtual CPU, a virtual I / O device, and a virtual memory. The virtual machine is constructed (generated) by assigning as Each guest OS is loaded into a virtual machine and executed by a virtual CPU in the virtual machine. As described above, the VMM allocates physical resources such as a real CPU, a real I / O device, and a real memory to each guest OS, thereby providing an environment in which each guest OS can operate simultaneously, and managing the virtual machine system. Do.

  The VMM generally provides one or more means (methods) for the guest OS to communicate with each other, such as a virtual network or a proprietary message protocol. Usually, in the communication between guest OSes, specific processing is required at the time of reception. For example, if there is a received packet, an analysis process is performed, or an acknowledge is returned to the transmission side.

  Notification of reception is often performed by interruption. In a general virtual machine system, when a certain guest OS is in an interrupt state, a CPU execution time is assigned to the guest OS. However, since it is generally not preferable that the interrupt processing time is long, in practice, in the interrupt processing, only the necessary minimum of the above processing is performed, and most of the rest is often performed after the interrupt is released.

  As described above, the processing after reception is generally performed after canceling the interrupt, but it is expected to be executed immediately after the reception interrupt. However, in a virtual machine execution environment in which a plurality of guest OSs exist, there is a possibility that dispatching to a guest OS other than the recipient is made because the interrupt is canceled.

Non-Patent Documents 1 to 3 describe, for example, methods used for adjusting a schedule (guest OS schedule) for executing a plurality of guest OSs in a time-sharing manner with the dispatch. Non-Patent Document 1 describes a description of CPU dispatch of a virtual machine. Here, “Time Slice Quantum” as a CPU allocation unit is described. Non-Patent Documents 2 and 3 describe the contents related to dispatcher and scheduling of virtualization software “Xen” that is developed in an open source on a personal computer. It describes a deadline-based scheduler policy called “sefd scheduler”.
Yoshio Okazaki, Minoru Minoru, “OS Series 11 VM”, Kyoritsu Publishing Co., Ltd., August 1989, p. 97-100 Hirokazu Takahashi, “Virtual Machine Monitor Xen3.0 Decoding Room 3rd Domain Scheduling (1)”, Open Source Magazine, June 2006, Softbank Creative Corporation, pages 161-170 Hirokazu Takahashi, “Virtual Machine Monitor Xen3.0 Decoding Room 4th Domain Scheduling (2)”, Open Source Magazine, July 2006, Softbank Creative Corp., pp. 147-155

  In the virtual machine system as described above, the dispatch policy of the guest OS affects the communication efficiency. Here, as the communication between guest OSes, for example, the following two characteristic models can be considered.

  (1) The first is communication (one-to-one communication) that is alternately performed as a series of related processes regularly between a pair of guest OSs. Such communication (hereinafter referred to as first type communication) occurs when a pair of guest OSs work in cooperation.

  (2) Second is communication frequently performed between one guest OS and a plurality of other guest OSs (that is, communication frequently performed between a plurality of guest OSs). There is no relationship between them. Such communication (hereinafter referred to as second type communication) occurs when server-client model communication is performed.

  Now, in the virtual machine system, the guest OS can only operate while being dispatched the CPU time by the VMM. Therefore, the communication performance (throughput or response) between the guest OSs greatly depends on the dispatching policy of the guest OS by the VMM.

  For example, in the first communication, if there is a process to be performed on one guest OS and the CPU time is allocated to the other guest OS, the throughput does not proceed as a result, and the throughput decreases. On the other hand, in the second communication, if the guest OS is dispatched for each communication, the efficiency of the system may be deteriorated due to the dispatch cost.

  As described above, communication between guest OSs and dispatch of guest OSs have a great relationship in terms of efficiency. However, Non-Patent Documents 1 to 3 do not describe schedule adjustment for dispatching the guest OS in consideration of this point.

  The present invention has been made in view of the above circumstances, and its purpose is to adjust the schedule for dispatching the guest OS so that the reception processing after the reception interrupt is canceled in the reception-side guest OS can be performed quickly. Accordingly, it is an object of the present invention to provide a virtual machine system capable of efficiently performing communication between guest OSes and a schedule adjustment method in the system.

  According to one aspect of the present invention, a virtual machine system is provided in which a plurality of guest OSs are executed in a time-sharing manner in a virtual machine execution environment provided by a virtual machine manager operating on a physical machine including a CPU. In this virtual machine system, the virtual machine manager is an interrupt management means for managing an interrupt to an arbitrary guest OS among the plurality of guest OSs, and is a reception given to the virtual machine manager from a sending guest OS. An interrupt management unit that receives a request for communication between guest OSs from the sending guest OS to the receiving guest OS and notifies the receiving guest OS of reception of transmission data from the sending guest OS, and a plurality of guest OSs. A scheduler for managing a schedule for execution in a time-sharing manner, when an interrupt factor to an arbitrary guest OS among the plurality of guest OSs occurs and the factor is the reception interrupt, Arbitrary guest OS is used as the receiving guest OS for reception processing after the reception interrupt is canceled. A scheduler that adjusts the schedule so that a necessary CPU time is additionally allocated to the receiving guest OS, and a dispatcher that dispatches the plurality of guest OSs according to the schedule adjusted by the scheduler. And

  According to the present invention, when the cause of an interrupt to a guest OS is reception of inter-guest OS communication that requires notification by a reception interrupt, the reception interrupt is canceled in the guest OS (that is, the receiving guest OS). The schedule is adjusted so that the CPU time required for the subsequent reception process is additionally allocated to the guest OS. As a result, the receiving guest OS can perform the receiving process quickly using the CPU time allocated additionally, and as a result, the communication efficiency between the guest OSs is improved, and the processing efficiency of the entire virtual machine system is improved. Can be improved.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 is a block diagram showing a configuration of a virtual machine system (VM system) according to an embodiment of the present invention. The virtual machine system shown in FIG. 1 is realized using a physical machine 1. A physical computer (real computer) 1 includes hardware (HW) 10 that provides an execution environment of a virtual computer. The HW 10 includes a CPU (real CPU) 11, an I / O (input / output) device (real I / O device) 12, and a memory (real memory) 13.

  On the HW 10 of the physical computer 1, a virtual machine manager (VMM) 20 operates. The VMM 20 manages the virtual machine system and constructs an environment (virtual machine execution environment) in which the virtual machine operates. More specifically, the VMM 20 controls physical resources (hardware resources) such as the CPU 11, I / O 12, and memory 13 that constitute the HW 10 of the physical computer 1, and at the same time, area of the physical resources. By managing various distributions, a virtual machine execution environment in which a plurality of virtual machines, for example, three virtual machines (VM) 30-1, 30-2, 30-3 operate is provided. In each of the VMs 30-1, 30-2, and 30-3, the VMM 20 controls the CPU 11, the I / O 12 and the memory 13 of the physical computer 1 in a virtual CPU, virtual I / O (not shown) in terms of time and area. It is constructed by allocating as memory (VM 30-1, 30-2, 30-3).

  On the VMs 30-1, 30-2, and 30-3, guest OSs 31-1 (OS # 1), 31-2 (OS # 2), and 31-3 (OS # 3) operate. More specifically, the guest OSs 31-1 to 31-3 are loaded into the VMs 30-1 to 30-3, respectively, and are executed by the virtual CPUs in the VMs 30-1 to 30-3. Guest OS numbers 1 to 3 are assigned to the guest OSs 31-1 to 31-3, respectively.

The VMM 20 includes a guest OS communication management unit 21, a guest OS execution management unit 22, an interrupt management unit 23, and a guest OS context management unit 24.
The guest OS communication management unit 21 is a module that manages communication between the guest OSs 31-1 to 31-3 and provides functions for the communication (communication means such as a transmission procedure and a reception procedure). In this embodiment, the communication means between guest OSs exchanges data by copying data packets from the guest OS at the transmission source (transmission side) to the reception buffer of the guest OS at the transmission destination (reception side). If there is, it is not limited to this. For example, the communication means may exchange information via a memory space shared between the sending guest OS and the receiving guest OS. When there are a plurality of communication means between guest OSes, a plurality of guest OS communication management units 21 may exist according to the type of communication means.

  The guest OS communication management unit 21 provides a guest OS with a guest OS communication interface (inter-guest OS communication IF) as a communication means between guest OSes. In the example of FIG. 1, the guest OS communication management unit 21 (the guest OS communication management unit 21 in the VMM 20) provides a guest OS communication IF 210 to the guest OSs 31-1 and 31-2, respectively. It is shown. Each of the guest OSs 31-1 and 31-2 uses the inter-guest OS communication IF 210 to request the VMM 20 to transmit data to another guest OS or acquire data received from another guest OS. Here, if the guest OS communication IF 210 is provided to the guest OS 31-3, the guest OS 31-3 also requests the VMM 20 to transmit or acquire data in the same manner as the guest OSs 31-1 and 31-2. can do.

  The guest OS communication management unit 21 includes a guest OS communication monitoring unit 211. The guest OS communication monitoring unit 211 is configured so that the guest OS communication management unit 21 performs a guest OS 31-i (i = 1, 2, 3) on the transmission side and a guest OS 31-j (j = 1, 2, 3, However, the status of the inter-guest OS communication using the inter-guest OS communication IF 210 provided for j ≠ i) is monitored. Based on the monitoring result, the guest OS inter-communication monitoring unit 211 determines a CPU time (CPU execution time) used as a CPU additional allocation time necessary for a reception process described later in the guest OS 31-j on the receiving side.

  The guest OS execution management unit 22 manages the execution of the guest OSs 31-1 to 31-3. The guest OS execution management unit 22 includes a guest OS scheduler 221, a CPU time allocation table 222, and a dispatcher 223.

  The guest OS scheduler 221 manages when and for how long the CPU 11 is assigned as a virtual CPU to each guest OS 31-1 to 31-3, that is, how much CPU time (CPU execution time) is assigned. It is a module to do.

  The CPU time allocation table 222 is a data table that holds a schedule (information) for dispatching the guest OSs 31-1 to 31-3. More specifically, the CPU time allocation table 222 is a data table that represents a schedule (schedule) of how much CPU time is allocated to each guest OS 31-1 to 31-3 at what time. The schedule (information) represented (held) by the CPU time allocation table 222 can be changed dynamically. In FIG. 1, the CPU time allocation table 222 is included in the guest OS execution management unit 22 of the VMM 20, but is physically used, for example, in the memory 13.

  FIG. 2 shows a schedule example indicated by the CPU time allocation table 222. In the schedule shown in FIG. 2, the CPU time allocation schedule from the present to the time point of 24 ms ahead is set. Here, it is shown that 24 ms is divided into 12 every 2 ms, and the CPU time is scheduled to be allocated to the three guest OSs 31-1 to 31-3 in units of 2 ms (frames) in round robin. The numbers in each frame divided into 12 represent guest OS numbers. The CPU time allocation table 222 is updated by the guest OS scheduler 221. Here, the CPU time allocation table 222 is updated at the timing when the context switch (dispatch to another guest OS) of the guest OS actually occurs.

  The dispatcher 223 is a module for switching the guest OS currently being executed using the CPU 11 to another guest OS based on the CPU time allocation table 221. That is, the dispatcher 223 dispatches guest OSs according to the CPU time allocation order (in the example of FIG. 2, the order from the left end to the right end) shown in the CPU time allocation table 222. Instead of scheduling based on a frame-by-frame schedule table such as the CPU time allocation table 222 shown in FIG. 2, scheduling using a priority queue can be applied.

  The interrupt management unit 23 manages an interrupt to the guest OS. One of the interrupts to the guest OS is a reception interrupt. The reception interrupt is an interrupt for notifying the guest OS 31-j of reception of transmission data associated with communication (inter-guest OS communication) from the transmission-side guest OS 31-i to the reception-side guest OS 31-j.

  The guest OS context management unit 24 generates guest OS contexts 241-1 to 241-3 that are sets of information necessary for executing the guest OSs 31-1 to 31-3. In FIG. 1, the guest OS contexts 241-1 to 241-3 are included in the guest OS context management unit 24 of the VMM 20, but physically stored in a memory area provided by the memory 13, for example.

  FIG. 3 shows an example of the data structure of the guest OS context 241-i (i = 1, 2, 3). The guest OS context 241-i includes guest OS specific data 242, an interrupt factor register 243, and CPU additional allocation time information 244.

The guest OS specific data 242 is information including the CPU register state when the guest OS is switched.
The interrupt factor register 243 is an interrupt factor holding management unit configured by a group of bits for identifying the interrupt factor when an interrupt occurs in the guest OS 31-i. The interrupt factor register 243 includes a guest OS communication reception bit. The guest OS communication reception bit is a specific bit indicating that an interrupt to the guest OS 31-i is an interrupt for notifying the guest OS 31-i that transmission data is received by communication between guest OSs, that is, a reception interrupt. . This guest OS communication reception bit is turned ON when transmission data by communication between guest OSs is received by the guest OS 31-i (in this embodiment, copied to the reception buffer of the guest OS 31-i). The interrupt factor register 243 is realized, for example, by mapping a physical register included in the HW 10 of the physical computer 1 to an execution environment (virtual computer execution environment) of the VM 30-i in which the guest OS 31-i operates. To do. However, the interrupt factor register 243 may be a virtual register created by the VMM 20.

  The CPU additional allocation time information 244 is a variable representing the value of the CPU time (CPU additional allocation time) additionally allocated to the guest OS 31-i when the guest OS 31-i receives communication from another guest OS. is there. For the CPU additional allocation time information 244, a value indicating a CPU time (CPU execution time) required for a process (reception process) associated with data reception on the reception side of the communication between guest OSs is used. In this embodiment, it is assumed that a value of 4 ms is set as the CPU additional allocation time information 244. However, the CPU additional allocation time information 244 is dynamically changed by a CPU additional allocation time setting unit 240 described later. The CPU additional allocation time information 244 is a variable that does not need to be referenced from the guest OS 31-i. In addition, when there are a plurality of means for communication between guest OSes, a variable (CPU additional allocation time information 244) corresponding to each means may be set.

  Referring back to FIG. 1, the guest OS context management unit 24 includes a CPU additional allocation time setting unit 240. The CPU additional allocation time setting unit 240 receives the guest OS 31-j (j = 1, j) on the receiving side based on the monitoring result of the communication status between guest OSes by the guest OS communication monitoring unit 211 in the guest OS communication management unit 21. The CPU time (CPU execution time) required for the reception process in (2) and (3) is determined as the CPU additional allocation time. The CPU additional allocation time setting unit 240 changes the setting of the CPU additional allocation time information 244 included in the guest OS context 241-j to the determined CPU additional allocation time value.

  As described above, the CPU time required for the reception process in the guest OS 31-j on the receiving side is dynamically set as the CPU additional allocation time according to the state of the communication between the guest OSs. Processing can proceed efficiently.

  Note that the CPU additional allocation time information 244 included in each guest OS context 241-j is obtained by using, for example, a CPU additional allocation at the time of system startup using a setting file in which the setting value of the CPU additional allocation time for each guest OS 31-j is stored. A configuration in which the time setting unit 240 sets is also possible. Here, it is assumed that the I / O 12 included in the HW 10 is a disk drive such as a hard disk drive. In this case, the above setting file is created in advance by a user operation and stored in the disk drive (I / O 12), and the CPU additional allocation time setting unit 240 reads the setting file from the disk drive when the system is started. Thus, the CPU additional allocation time information 244 included in each guest OS context 241-j may be set based on the setting file.

  As described above, even if the method of setting the CPU additional allocation time information 244 included in each guest OS context 241-j is applied based on the setting file created in advance by the user's operation, the user can apply each guest OS 31- When the processing contents of j are well known, it is possible to set an appropriate CPU additional allocation time for each guest OS 31-j, so that the processing of the entire system can be efficiently performed.

  Further, depending on whether or not a valid CPU additional allocation time value is given as the CPU additional allocation time information 244, it is added to the guest OS 31-j immediately after the interrupt processing associated with the reception interrupt generation for the guest OS 31-j. It is also possible to determine whether to give the CPU time (CPU additional allocation time).

Next, an outline of the operation in the virtual machine system of FIG. 1 will be described.
First, it is assumed that a certain guest OS 31-j has received transmission data for communication between guest OSes from another guest OS (transmission-side guest OS) 31-i via the VMM 20. In such a case, the interrupt management unit 23 in the VMM 20 notifies the guest OS 31-j (that is, the reception guest OS 31-j) that the transmission data is received from the transmission guest OS 31-i. -j Interrupt (receive interrupt) is generated.

  In many communication forms, the reception-side guest OS 31-j needs to perform processing (reception processing) associated with reception such as analysis of received data (for example, packet data) and return of an acknowledgment (ACK) after data reception. . In general, guest OSs are often based on those operating in a normal computer environment that is not a virtual computer execution environment. Such a guest OS often implements interrupt processing and reception processing separately. Therefore, in the prior art, most of the reception processing by the reception-side guest OS 31-j is generally performed not after the reception of data but after the cancellation of the interrupt.

  FIG. 4 is a diagram for explaining the problem of the schedule (CPU time allocation schedule) for the guest OSs 31-1 to 32-3 represented by the CPU time allocation table 222. In FIG. 4, the time point t0 is the current time point, and the time 24 ms from the time point t0 to the time point tn 24 ms ahead is divided into 12 parts every 2 ms and managed. In the example of FIG. 4, from the time point t0, the guest OS 31-2 → guest OS 31-3 → guest OS 31-1 → guest OS 31-2, etc. in units of 2 ms from the time t0 to the three guest OSs 31-1 to 31-3. Is scheduled to be assigned in round robin.

  Assume that the execution of the guest OS 31-2 is started as a result of the CPU 11 being assigned to the guest OS 31-2 at time t0. For example, the guest OS (transmission-side guest OS) 31-2 communicated with the guest OS (reception-side guest OS) 31-1 via the VMM 20 at time t1 when, for example, 1 ms has elapsed from time t0. And

  In this case, the interrupt management unit 23 of the VMM 20 turns on the inter-guest OS communication reception bit of the interrupt factor register 243 included in the guest OS context 241-1 unique to the reception-side guest OS 31-1.

  In the prior art, the dispatcher 223 included in the guest OS execution management unit 22 of the VMM 20 confirms that the receiving guest OS 31-1 is in an interrupt state and checks the interrupt handler (see FIG. Dispatch temporarily to (not shown). The interrupt handler of the guest OS 31-1 confirms the interrupt factor based on the ON state of the inter-guest OS communication reception bit of the interrupt factor register 243 included in the guest OS context 241-1 unique to the guest OS 31-1. Interrupt processing for turning off the reception bit is performed. Then, the interrupt handler of the guest OS 31-1 notifies the VMM 20 of the interrupt release at an early stage (before performing the actual reception process) after the interrupt process.

  In the prior art, when the dispatcher 223 of the VMM 20 receives a notification of interrupt cancellation from the guest OS 31-1, the guest OS 31 is assigned the CPU 11 temporarily assigned to the guest OS 31-1 according to the schedule indicated by the CPU time allocation table 222. Return to -2. As a result, the guest OS 31-2 is dispatched again. Here, it is assumed that the guest OS 31-1 needs a time of, for example, 4 ms for receiving data transmitted from the guest OS 31-2. In this case, according to the conventional technique, the guest OS 31-1 finishes the reception process at the time t2 when the CPU time of 2 ms is allocated twice to the guest OS 31-1 and the second CPU time elapses. is there. As is apparent from FIG. 4, this time point t2 is the time point when 10 ms has elapsed from the time point t0 (that is, the start time point of the schedule indicated by the CPU time allocation table 222).

  The sending guest OS 31-2 waits for an ACK returned from the guest OS 31-1 after the receiving process of the guest OS 31-1 for the data sent to the receiving guest OS 31-1, and resumes its own processing. Sometimes. However, in the prior art, the receiving process of the receiving guest OS 31-1 ends at time t2 when 10 ms elapses from time t0. Between the time point t0 and the time point t2, the CPU 11 is assigned twice to the transmission side guest OS 31-2 in units of 2ms (that is, CPU time of 2ms).

  In the prior art, ACK is not returned from the receiving guest OS 31-1 within the CPU time allocated twice to the sending guest OS 31-2. For this reason, the transmission side guest OS 31-2 cannot resume the processing in the CPU time allocated twice, and the CPU time is wasted. From this, the present inventor has come to recognize that it is advantageous that the reception process in the guest OS on the receiving side is quickly performed when the communication between guest OSs is performed.

  Therefore, in this embodiment, when an interrupt of communication between guest OSs to the receiving guest OS 31-1 occurs, the CPU time is additionally added to the guest OS 31-1 even after the interrupt is released due to the end of the interrupt processing corresponding to the interrupt. Is allocated to the CPU time allocation table 222 by the guest OS scheduler 221 of the VMM 20.

  FIG. 5 shows an example of the schedule represented by the CPU time allocation table 222 after the change. In the example of FIG. 5, a reception interrupt to the receiving guest OS 31-1 occurs at time t1, and the CPU time is given to the guest OS 31-1 for a period from time t1 to time t3 when 4 ms necessary for reception processing elapses. (CPU additional allocation time) is allocated. As a result, the reception-side guest OS 31-1 can complete the reception process between the start time t0 of the schedule indicated by the CPU time allocation table 222 and the time t3 when 5 ms elapses.

  As described above, in this embodiment, the CPU time allocation table 222 is changed based on the CPU additional allocation time information 244 included in the guest OS context 241-1 unique to the reception-side guest OS 31-1. As shown in FIG. 5, the CPU time allocation schedule is changed. As a result, as compared with the case where the receiving guest OS 31-1 is dispatched according to the schedule shown in the original CPU time allocation table 222 as shown in FIG. The reception process of the guest OS 31-1 can be completed quickly. As a result, the processing of the sending guest OS 31-2 can also be advanced quickly.

Next, the procedure of schedule adjustment processing for completing the reception processing of the guest OS on the receiving side as described above will be described with reference to the flowchart of FIG.
First, it is assumed that the sending guest OS 31-2 calls the guest OS communication IF 210 to the VMM 20 for communication between guest OSs with the receiving guest OS 31-1. In this embodiment, the calling of the guest OS communication IF 210 is realized by issuing a guest OS communication IF call command to the VMM 20 from the sending guest OS 31-2.

  The guest OS communication management unit 21 of the VMM 20 receives the call of the guest OS communication IF from the transmission side guest OS 31-2, and each of the guest OS 31-2 and the guest OS 31-1 on the reception side respectively. A guest OS communication IF 210 is provided (step S1). As a result, the sending guest OS 31-2 can send data to the receiving guest OS 31-1 (the receiving buffer) via the VMM 20 using the guest OS communication IF 210.

  Then, the interrupt management unit 23 of the VMM 20 turns on the inter-guest OS communication reception bit of the interrupt factor register 243 included in the guest OS context 241-1 unique to the reception-side guest OS 31-1 (step S2).

  The guest OS scheduler 221 of the VMM 20 generates a dispatch of the guest OS 31-1 accompanying the occurrence of an interrupt to the receiving guest OS 31-1 when any interrupt factor to the receiving guest OS 31-1 occurs. Immediately before the step S11 is executed. In step S11, the guest OS scheduler 221 determines whether or not the guest OS communication reception bit of the interrupt factor register 243 included in the guest OS context 241-1 unique to the reception-side guest OS 31-1 is ON. That is, in step S11, the guest OS scheduler 221 determines whether the cause of the interruption to the reception-side guest OS 31-1 is reception of inter-guest OS communication in the reception-side guest OS 31-1 that requires notification by reception interruption. judge. Note that when the interruption (reception interruption) to the reception-side guest OS 31-1 occurs depends on the implementation of the system and does not have to be immediately after step S2.

  If the reception interrupt bit is in the ON state, and the cause of the interruption to the reception-side guest OS 31-1 is reception of communication between guest OSs (step S11), the guest OS scheduler 221 executes step S12. In this step S12, the guest OS scheduler 221 determines whether or not the CPU additional allocation time information 244 included in the guest OS context 241-1 unique to the receiving guest OS 31-1 indicates a valid CPU additional allocation time value. judge.

  If the CPU additional allocation time information 244 indicates a valid CPU additional allocation time value (step S12), the guest OS scheduler 221 determines the CPU as described above based on the CPU additional allocation time value. The time allocation table 222 is changed (step S13). Here, immediately after the interrupt processing accompanying the occurrence of an interrupt (reception interrupt) to the reception-side guest OS 31-1, the CPU time (CPU additional allocation time) indicated by the CPU additional allocation time information 244 is allocated to the guest OS 31-1. As described above, the CPU time allocation table 222 is changed (updated). If the CPU additional allocation time allocated to the reception-side guest OS 31-1 cannot be covered within the schedule range indicated by the CPU time allocation table 222, it can be solved by creating a further schedule.

  When the CPU time allocation table 222 is changed by the guest OS scheduler 221 (step S13), the interrupt management unit 23 generates an interrupt (reception interrupt) to the reception-side guest OS 31-1 (step S14).

  On the other hand, if the reception interrupt bit is not in the ON state, and the cause of the interrupt to the reception-side guest OS 31-1 is not reception of communication between guest OSs (step S11), steps S12 and S13 are skipped and An interrupt to the corresponding receiving guest OS 31-1 (an interrupt different from the reception interrupt) is generated (step S14). If it is determined in step S12 that the CPU additional allocation time information 244 does not indicate a valid CPU additional allocation time value, step S13 is skipped and an interruption (reception) to the reception-side guest OS 31-1 is received. Interrupt) is generated (step S14).

  Next, the CPU additional allocation time information 244 unique to the guest OS 31-j, that is, the value of the CPU time (CPU additional allocation time) necessary for the reception processing in the guest OS 31-j, which is applied in the above embodiment, is always optimal. A processing procedure for optimizing system communication by dynamically changing to a value will be described.

  The system communication includes the first type of communication in which the guest OS 31-i and the guest OS 31-j constantly and alternately communicate with each other and the plurality of guest OSs 31-1 to 31-3 frequently communicate with each other. The second type of communication is roughly classified. Therefore, system optimization in a situation where the first type communication is performed and system optimization in a situation where the second type communication is performed will be sequentially described.

<Optimization of the system in the situation where the first type of communication is performed>
First, a processing procedure for optimizing the system in a situation where the first type of communication is performed will be described with reference to a flowchart of FIG.

  In a situation where the guest OSs 31-1 to 31-3 operating on the VMs 30-1 to 30-3 are performing the first type of communication (steady one-to-one alternate communication), the guest OSs 31-1 to 31-3 A reception interrupt to 31-3 occurs regularly. When a reception interrupt to the guest OS 31-j occurs, the guest OS 31-j (j = 1, 2, 3) executes the above-described reception process immediately after the interrupt process. The CPU additional allocation time setting unit 240 in the guest OS context management unit 24 sets the CPU additional allocation time setting value so that the CPU time additionally allocated to the guest OS 31-j (CPU additional allocation time) becomes an optimum value. (CPU additional allocation time information 244) is adjusted by the procedure according to the flowchart of FIG. This adjustment is performed as follows by cooperating with the inter-guest OS communication monitoring unit 211 in the inter-guest OS communication management unit 21.

  First, the inter-guest OS communication monitoring unit 211 detects a guest OS that is regularly performing one-to-one communication (first type communication) by monitoring communication between guest OSes (step S21). ). As described above, in order to detect a guest OS that regularly performs one-to-one communication, for example, the guest OS communication monitoring unit 211 calls the guest OS communication IF 210 from the guest OSs 31-1 to 31-3. You can collect the logs. Here, from the call log of the inter-guest OS communication IF 210, for example, it is determined that the number of times the guest OS 31-i and the guest OS 31-j alternately call the inter-guest OS communication IF 210 exceeds a predetermined threshold. If possible, the inter-guest OS communication monitoring unit 211 detects that the guest OS 31-i and the guest OS 31-j are regularly performing one-to-one communication (first type communication). it can.

  The CPU additional allocation time setting unit 240 monitors the communication between guest OSs if the guest OS 31-i and the guest OS 31-j are regularly communicating on a one-to-one basis (first type communication). When detected by the unit 211 (step S21), for example, the CPU additional allocation time information 244 specific to both the guest OS 31-i and 31-j is changed, and the CPU additional allocation time is set to, for example, twice the current. (Step S22).

  In this state, the inter-guest OS communication monitoring unit 211 observes the communication status between the guest OSs 31-i and 31-j, for example, the communication throughput (step S23). Then, the guest OS communication monitoring unit 211 determines whether or not the communication throughput has improved (step S24). In the present embodiment, the number of communications per fixed time is used as the communication throughput.

  If it is determined by the guest OS communication monitoring unit 211 that the throughput has improved (step S24), the CPU additional allocation time setting unit 240 further sets the CPU additional allocation time of each of the guest OSs 31-i and 31-j. It is set to 2 times (step S25a). Conversely, if the guest OS communication monitoring unit 211 determines that the throughput has deteriorated (step S24), the CPU additional allocation time setting unit 240 determines the CPU additional allocation time of each of the guest OSs 31-i and 31-j. Reset to half of the current value (step S25b).

  In either case, the guest OS inter-communication monitoring unit 211 observes and determines the communication status (throughput) (steps S26a and S27a or steps S26b and S27b) as in the previous steps S23 and S24.

  If it is determined in step S27a that the throughput has improved, the CPU additional allocation time setting unit 240 executes step S25a again, and further sets the CPU additional allocation time to double. Then, the guest OS inter-communication monitoring unit 211 again performs observation and determination of the communication status (throughput) (steps S26a and S27a). On the other hand, when it is determined in step S27a that the throughput has deteriorated, the CPU additional allocation time setting unit 240 resets the CPU additional allocation time to half of the current value (step S28a). The CPU additional allocation time setting unit 240 ends the process, assuming that the latest CPU additional allocation time value set in step S28a is the optimum value.

  On the other hand, if it is determined in step S27b that the throughput has improved, the CPU additional allocation time setting unit 240 executes step S25b again to reset the CPU additional allocation time to half the current value. Then, the guest OS inter-communication monitoring unit 211 performs the observation and determination of the communication status (throughput) (steps S26b and S27b) again. On the other hand, when it is determined in step S27b that the throughput has deteriorated, the CPU additional allocation time setting unit 240 sets the CPU additional allocation time to double the current time (step S28b). The CPU additional allocation time setting unit 240 ends the process, assuming that the latest CPU additional allocation time value set in step S28b is the optimum value.

  Note that it is also possible to provide a restriction on the adjustment range of the CPU additional allocation time, set a range in which the CPU additional allocation time can be controlled as the adjustment range, and adjust the CPU additional allocation time so as not to exceed this range. .

  In the above embodiment, the CPU additional allocation time of both the guest OSs 31-i and 31-j performing the first type of communication is changed to the optimum value. However, one of the guest OSs 31-i and 31-j, for example, may be configured such that only the CPU additional allocation time of the guest OS on the response return side (reception side) is changed to the optimum value. In this configuration, the inter-guest OS communication monitoring unit 211 determines whether the ratio at which one of the guest OSs 31-i and 31-j returns a response exceeds a predetermined threshold based on the observation result of the communication status. It is sufficient to determine whether the one is mainly the receiving guest OS.

<Optimization of the system in a situation where the second type of communication is performed>
In a situation where the guest OSs 31-1 to 31-3 are performing the second type of communication (a situation where frequent communication is performed), dispatch due to a reception interrupt frequently occurs. In such a situation, there is a possibility of causing a decrease in system performance due to the overhead effect on the dispatch itself. For example, the communication of the server client model corresponds to the second type of communication. When such communication is performed by an application on the guest OS, each communication is independent.

  Accordingly, in many cases, no contradiction occurs in the operation of the entire system even if the reception process is not performed immediately after the interrupt process associated with the reception interrupt to the reception-side guest OS. In this case, when the reception amount is accumulated to some extent and the reception side guest OS executes the reception processing collectively, the number of dispatches may be reduced and the throughput may be improved.

  Hereinafter, a processing procedure for optimizing the system in a situation where the second type of communication is performed will be described with reference to a flowchart of FIG.

The guest OS communication monitoring unit 211 monitors the communication between guest OSes, so that the number of reception interrupts increases due to a large amount of communication, that is, frequent communication between guest OSes (second type). It is detected that communication is being performed (step S31). In order to detect such communication, for example, the guest OS communication monitoring unit 211 may collect a call log of the guest OS communication IF 210 from the guest OSs 31-1 to 31-3. Here, if it can be determined from the call log of the inter-guest OS communication IF 210 that the number of reception interrupts per fixed time exceeds a predetermined threshold, the inter-guest OS communication monitoring unit 211 determines that the guest OS 31-1 It can be detected that communication (second type communication) is frequently performed between ˜31-3. Here, it is assumed that the guest OS 31-1 operates as a server, and the guest OSs 31-2 and 31-3 operate as clients. That is, the CPU additional allocation time setting unit 240 operating with the guest OSs 31-2 and 31-3 as the transmission side and the guest OS 31-1 as the reception side is frequently used between the guest OSs 31-1 to 31-3. When communication (second type communication) is detected by the guest OS communication monitoring unit 211 (step S31), step S32 is executed. In this step S32, the CPU additional allocation time setting unit 240 sets a reception amount threshold (reception amount threshold) necessary to generate a reception interrupt to the reception-side guest OS 31-1, for example, twice the current value. At the same time, the CPU additional allocation time information 244 unique to the guest OS 31-1 is changed to set the CPU additional allocation time to, for example, twice the current time. That is, the CPU additional allocation time setting unit 240 sets both the reception amount threshold of the guest OS 31-1 and the CPU additional allocation time to be twice the current value.

  In this state, the inter-guest OS communication monitoring unit 211 observes the communication status between the guest OS 31-1 and the guest OSs 31-2 and 31-3, for example, the communication throughput (step S33). Then, the guest OS communication monitoring unit 211 determines whether or not the communication throughput has improved (step S34). In the present embodiment, as described above, the number of communications per fixed time is used as the communication throughput.

  If it is determined by the guest OS communication monitoring unit 211 that the throughput has improved (step S34), the CPU additional allocation time setting unit 240 determines the reception amount threshold of the guest OS 31-1 and the CPU additional allocation time. Is set to twice the current value (step S35a). Conversely, if the guest OS communication monitoring unit 211 determines that the throughput has deteriorated (step S34), the CPU additional allocation time setting unit 240 sets the reception amount threshold value and CPU additional allocation time of the guest OS 31-1 to In either case, the value is reset to half of the current value (step S35b).

  In any case, the guest OS inter-communication monitoring unit 211 observes and determines the communication status (throughput) (steps S36a and S37a or steps S36b and S37b) as in the previous steps S32 and S33.

  If it is determined in step S37a that the throughput has improved, the CPU additional allocation time setting unit 240 executes step S35a again to further double the reception amount threshold value and CPU additional allocation time of the guest OS 31-1. To do. Then, the guest OS inter-communication monitoring unit 211 executes the observation and determination (steps S36a and S37a) of the communication state (throughput) again. On the other hand, if it is determined in step S37a that the throughput has deteriorated, the CPU additional allocation time setting unit 240 resets the reception amount threshold of the guest OS 31-1 and the CPU additional allocation time to half of the current values (step S37a). S38a). The CPU additional allocation time setting unit 240 terminates the process, assuming that the latest reception amount threshold value and CPU additional allocation time value set in step S38a are optimum values.

  On the other hand, if it is determined in step S37b that the throughput has improved, the CPU additional allocation time setting unit 240 executes step S35b again, and sets the reception threshold value and CPU additional allocation time of the guest OS 31-1 to half of the current value. Set to. Then, the guest OS inter-communication monitoring unit 211 again performs observation and determination of the communication status (throughput) (steps S36b and S37b). On the other hand, if it is determined in step S37b that the throughput has deteriorated, the CPU additional allocation time setting unit 240 sets the reception amount threshold and the CPU additional allocation time of the guest OS 31-1 to double the current time (step S38b). . The CPU additional allocation time setting unit 240 terminates the processing, assuming that the latest reception amount threshold value and CPU additional allocation time value set in step S38b are optimum values.

  Regarding the CPU additional allocation time, it is also possible to set a range in which the CPU additional allocation time is controllable as the adjustment range by adjusting the adjustment range, and to adjust the CPU additional allocation time so as not to exceed this range. It is.

[First Modification]
Next, a first modification of the above embodiment will be described.
In the above embodiment, the CPU time additionally allocated to the reception-side guest OS 31-j for the communication between guest OSs (that is, the CPU additional allocation time) is dynamically adjusted on the VMM 20 side. However, the transmission side guest OS 31-i of the communication between guest OSes predicts the time (CPU time) required for the reception process accompanying data reception in the reception side guest OS 31-j, and the CPU of the reception side guest OS 31-j It is also possible to adjust the additional allocation time. Such an adjustment method is optimal when the amount of CPU time required for the reception processing of the reception-side guest OS 31-j depends on the content of communication from the transmission-side guest OS 31-i, and more accurate time specification is possible. I can expect.

  A feature of the first modification is that the sending guest OS 31-i designates a temporary CPU additional allocation time of the receiving guest OS 31-j. Hereinafter, the temporary CPU additional allocation time designation of the receiving guest OS 31-j by the sending guest OS 31-i and the schedule adjustment procedure based on the designation will be described with reference to the flowchart of FIG.

  When the guest OS 31-i on the sending side of the inter-guest OS communication calls the inter-guest OS communication IF 210 to the VMM 20 for the inter-guest OS communication with the receiving guest OS 31-j, the receiving-side guest OS 31-i The time required for the reception process in the receiving guest OS 31-j is predicted from the content of the communication to be performed on j. The guest OS 31-i on the transmission side designates the predicted time as the CPU time (CPU additional allocation time) to be allocated to the reception guest OS 31-j, for example, by using an argument of the inter-guest OS communication IF call command. The guest OS communication IF 210 is called by issuing a command to the VMM 20.

  Then, the guest OS communication management unit 21 of the VMM 20 provides the guest OS communication IF 210 to each of the transmission side guest OS 31-2 and the reception side guest OS 31-1 (step S41). The interrupt management unit 23 turns on the inter-guest OS communication reception bit of the interrupt factor register 243 included in the guest OS context 241-1 unique to the reception-side guest OS 31-1 (step S42). In step S42, the CPU additional allocation time setting unit 240 sets the CPU time value designated by the sending guest OS 31-2 as the temporary CPU additional allocation time value of the receiving guest OS 31-1. Here, the value of the designated temporary CPU additional allocation time is set as a part of the guest OS context 241-1 unique to the reception-side guest OS 31-1. However, the temporary CPU additional allocation time value is set in a location (physically a specific area in the memory 13) prepared in association with the receiving guest OS 31-1 separately from the guest OS context 241-1. It may be configured as described above.

  Thereafter, the guest OS scheduler 221 of the VMM 20 immediately before the dispatcher 224 generates dispatch of the guest OS 31-1 accompanying the occurrence of an interrupt to the receiving guest OS 31-1, the guest OS context 241 unique to the guest OS 31-1. It is determined whether the guest OS communication reception bit of the interrupt factor register 243 included in -1 is in an ON state (step S51).

  If the reception interrupt bit is in the ON state, that is, if the cause of the interrupt to the reception-side guest OS 31-1 is reception of communication between guest OSs (step S51), the guest OS scheduler 221 executes step S52. In step S52, the guest OS scheduler 221 determines whether the value of the temporary CPU additional allocation time set in the guest OS context 241-1 unique to the reception-side guest OS 31-1 is a valid value.

  If the value of the temporary CPU additional allocation time is a valid value (step S52), the guest OS scheduler 221 uses the temporary CPU additional allocation time value as in step S13 of the above embodiment. Then, the CPU time allocation table 222 is changed (step S54). Here, immediately after the interrupt processing accompanying the occurrence of a reception interrupt to the reception-side guest OS 31-1, unlike the step S13 (not the CPU time indicated by the CPU additional allocation time information 244), the temporary CPU additional allocation time CPU time allocation table 222 is changed so that is allocated to the guest OS 31-1.

  On the other hand, if the value of the temporary CPU additional allocation time is not a valid value (step S52), the guest OS scheduler 221 uses the guest specific to the reception-side guest OS 31-1 as in step S12 of the above embodiment. It is determined whether the CPU additional allocation time information 244 included in the OS context 241-1 indicates a valid CPU additional allocation time value (step S53).

  If the CPU additional allocation time information 244 indicates a valid CPU additional allocation time value (step S53), the guest OS scheduler 221 performs the steps of the above embodiment based on the CPU additional allocation time value. As in S13, the CPU time allocation table 222 is changed (step S54).

  When the guest OS scheduler 221 changes the CPU time allocation table 222, the CPU additional allocation time setting unit 240 causes the CPU additional allocation time setting value to be deleted from the guest OS context 241-1 (step S55). If the value of the CPU additional allocation time is set in the guest OS context 241-1, the CPU additional allocation time setting unit 240 deletes the setting value. Then, the interrupt management unit 23 generates an interrupt (reception interrupt) to the reception-side guest OS 31-1 (Step S56).

  On the other hand, if the reception interrupt bit is not in the ON state (step S51), step S56 is executed without changing the CPU time allocation table 222, and an interrupt to the reception-side guest OS 31-1 (different from the reception interrupt). Interrupt). Even when it is determined in step S53 that the CPU additional allocation time information 244 does not indicate a valid CPU additional allocation time value, step S56 is executed without changing the CPU time allocation table 222. Then, an interrupt (reception interrupt) to the receiving guest OS 31-1 is generated.

[Second Modification]
Next, a second modification of the above embodiment will be described.
In the above embodiment, additional CPU time (CPU additional allocation time) is allocated to the receiving guest OS for the receiving process performed after the receiving interrupt process of the receiving guest OS. For this reason, there is a possibility that there is another guest OS whose CPU time is unreasonably taken.

  In the example of FIG. 5, as a result of the additional CPU time (CPU additional allocation time) being allocated to the guest OS 31-1, at the time t1 when 1 ms has elapsed from the time t0, the allocation is performed to the guest OS 31-2 and the guest OS 31-3. CPU time to be taken is taken away from the guest OS 31-2 and guest OS 31-3. In such a case, the guest OS 31-3 among the guest OS 31-2 and guest OS 31-3 whose CPU time has been deprived is the guest OS 31-1 (guest OS 31-1 to which additional CPU time is allocated) and the guest OS 31. Although it is not related to the communication between guest OSes performed with -2, the performance of the guest OS 31-3 may be deteriorated. Such a performance degradation becomes a problem particularly when the guest OS 31-3 is performing a process that requires real-time performance.

  The feature of the second modified example is that a guest OS to which CPU time is additionally allocated is called a first guest OS, and a guest OS that is deprived of CPU time is called a second guest OS. The CPU time taken away is to make up for the CPU time scheduled to be allocated to the first guest OS. In this compensation, the CPU time taken away from the second guest OS is assigned to the first guest OS in the time zone closest to the time zone (assignment scheduled time zone) where the assigned CPU time is scheduled. This is realized by exchanging with the scheduled CPU time.

  Hereinafter, a procedure of schedule adjustment realized by exchanging the CPU time taken away from the second guest OS with the CPU time scheduled to be assigned to the first guest OS will be described with reference to the flowchart of FIG.

  Assume that transmission data associated with communication from the transmission side guest OS 31-2 is received by the reception side guest OS 31-1, and a reception interrupt occurs in the reception side guest OS 31-1. In this case, the schedule needs to be changed.

  Then, the guest OS scheduler 221 does not have the CPU allocation time required for the reception processing performed after the interrupt processing in the reception side guest OS 31-1 at the CPU additional allocation time currently set for the reception side guest OS 31-1. (Step S61). Here, the value of the CPU allocation time necessary for the reception processing after the interrupt processing in the reception-side guest OS 31-1 is indicated by the CPU additional allocation time information 244 included in the guest OS context 241-1. Further, at the stage when step S61 is first executed, there is no time zone for the CPU additional allocation time set for the reception-side guest OS 31-1.

  If the CPU allocation time necessary for the receiving process after the interrupt process in the receiving guest OS 31-1 is insufficient, the guest OS scheduler 221 executes the process of step S62. In this step S62, the guest OS scheduler 221 refers to the CPU time allocation table 222, so that the reception side guest OS 31-1 will be moved to the reception side guest OS 31-1 in the nearest future outside the time zone of the CPU additional allocation time for the reception side guest OS 31-1. The CPU time (scheduled dispatch time) that is the time zone to be allocated is searched.

  Next, the guest OS scheduler 221 sets the CPU time scheduled to be allocated to another guest OS immediately after the CPU additional allocation time currently set for the receiving guest OS 31-1, in step S62. The CPU time scheduled to be allocated to the reception-side guest OS 31-1 searched for in step S63 is replaced (step S63). That is, the guest OS scheduler 221 adds the CPU time scheduled to be assigned to another guest OS immediately after the CPU additional allocation time period to the CPU additional allocation time for the receiving guest OS 31-1. The CPU time allocation table 222 performs an operation of changing the CPU time scheduled to be allocated to the receiving guest OS 31-1 searched for in step S62 for the other guest OS. At the stage when step S63 is first executed, there is no time zone for additional CPU allocation time set for the reception-side guest OS 31-1. In this case, the sending guest OS 31-2 communicates with the receiving guest OS 31-1 during the CPU time scheduled to be assigned to another guest OS immediately after the CPU additional assigning time. This is the time zone of the CPU time to which the point of time belongs, and the time zone of the CPU time for the sending guest OS 31-2.

  The guest OS scheduler 221 repeats steps S62 and S63 described above until there is no shortage of CPU time (CPU additional allocation time) that is additionally allocated to the reception-side guest OS 31-1 (step S61).

  FIG. 11 shows an example of the schedule before and after adjustment when the schedule for the guest OSs 31-1 to 32-3 is adjusted according to the procedure shown in the flowchart of FIG. In the example of FIG. 11, 2 ms of CPU time is allocated to the guest OS 31-2 at time t10. Assume that the guest OS 31-2 communicates with the guest OS 31-1 immediately after this CPU time allocation.

  The interrupt management unit 23 generates a reception interrupt of communication between guest OSs to the reception-side guest OS 31-1 at this time (time t10). Then, the guest OS scheduler 221 adjusts the schedule indicated by the CPU time allocation table 222. In this adjustment, as indicated by an arrow 111 in FIG. 11A, a time period from a time t10 scheduled to be assigned to the sending guest OS 31-2 at time t10 to a time t11 (= t10 + 2 ms). The 2 ms CPU time is replaced with the 2 ms CPU time in the time zone from the time t12 (= t10 + 4 ms) scheduled to be assigned to the receiving guest OS 31-1 at the time t12 to the time t13 (= t10 + 6 ms). Similarly, as indicated by an arrow 112 in FIG. 11A, a time period from time t11 (= t10 + 2 ms) scheduled to be assigned to the guest OS 31-3 at time t11 (= t10 + 2 ms) to time t12 (= t10 + 4 ms). The 2 ms CPU time is replaced with the 2 ms CPU time in the time period from the time t14 (= t10 + 10 ms) to the time t15 (= t10 + 12 ms) scheduled to be assigned to the receiving guest OS 31-1 at the time t14 (= t10 + 10 ms). Is done.

  As a result, as shown in FIG. 11B, immediately after the reception interruption at time t10, the CPU time of 4 ms that is originally scheduled to be sequentially assigned to the guest OSs 31-2 and 31-3 from time t10 to time t12. Are assigned to the receiving guest OS 31-1. On the contrary, the 2 ms CPU time from the time t12 to the time t13 and the 2 ms CPU time from the time t14 to the time t15, which are originally scheduled to be assigned to the receiving guest OS 31-1, are shown in FIG. As shown, guest OSs 31-2 and 31-3 are assigned respectively.

  As described above, in the example of FIG. 11, immediately after the reception interrupt at time t11, the reception-side guest OS 31-1 requires the reception processing in the guest OS 31-1 (included in the guest OS context 241-1). The schedule indicated by the CPU time allocation table 222 is changed so that the CPU time of the value indicated by the CPU additional allocation time information 244 is allocated. Further, the CPU time amount allocated to each of the guest OSs 31-1 to 31-3 is kept uniform within the scheduled range.

  In the second modified example, for simplification of explanation, it is assumed that the exchange is performed in units of CPU time originally scheduled to be assigned to the guest OSs 31-1 to 31-3. However, the reception interrupt generally occurs in the middle of the CPU time allocated to the guest OS being executed. In addition, the CPU time allocated to each guest OS may be different for each guest OS. In such a case, the guest OS scheduler 221 may adjust the schedule by dividing the CPU time scheduled to be assigned to each guest OS into a necessary amount of time (for example, the minimum time unit managed by the guest OS scheduler 221). . If the CPU time allocated to the receiving guest OS cannot be covered within the schedule, it can be solved by creating a further schedule.

[Third Modification]
Next, a third modification of the above embodiment will be described. The feature of the third modification is that the CPU time additionally allocated to the guest OS at the time of reception interruption to the receiving guest OS is covered by the scheduled CPU time allocated to the transmitting guest OS. As described above, in the third modification, a method of transferring the CPU time scheduled to be assigned to the transmission side guest OS is applied for the reception process performed after the reception interrupt process of the reception side guest OS. This technique can be applied, for example, to a communication model in a case where a response of the receiving guest OS is required for the progress of processing of the transmitting guest OS. In addition, this method does not affect the allocation of CPU time to the guest OS that is unrelated to the communication between guest OSs related to the reception-side guest OS (reception-side guest OS to which CPU time is additionally allocated).

  Hereinafter, the procedure of schedule adjustment realized by transferring the CPU time scheduled to be allocated to the transmission side guest OS for reception processing of the reception side guest OS will be described with reference to the flowchart of FIG.

  Now, it is assumed that the guest OS 31-1 has received communication transmission data from the guest OS (transmission-side guest OS) 31-2 and a reception interrupt has occurred in the guest OS (reception-side guest OS) 31-1. In this case, the schedule needs to be changed as in the second modification.

  Then, the guest OS scheduler 221 refers to the CPU time allocation table 222 and confirms the position on the schedule (that is, the current schedule position) indicated by the CPU time allocation table 222 at the reception interrupt time (step S71). Next, the guest OS scheduler 221 determines that the total amount of CPU time (CPU allocation scheduled time) scheduled to be allocated to the receiving guest OS 31-1 from the reception interrupt point to the most recently confirmed schedule position is the guest OS 31- It is determined whether it is equal to or greater than the value indicated by the CPU additional allocation time information 244 unique to 1 (that is, the time required for the reception processing of the guest OS 31-1) (step S72).

  If the total amount of the CPU allocation scheduled time described above is less than the time required for the reception process of the guest OS 31-1, (step S72), the guest OS scheduler 221 transmits the most recently confirmed schedule position. It is determined whether or not it is a scheduled dispatch position where the CPU time is allocated to the side guest OS 31-2 (step S73). If the determination in step S73 is YES, the guest OS scheduler 221 receives the corresponding schedule position for the sending guest OS 31-2 shown in the CPU time allocation table 222 (here, the current schedule position). Is changed to the side guest OS 31-1 (to be dispatched to) (step S74). That is, the CPU time allocation table 222 assigns the 2 ms CPU time that should originally be allocated to the transmission side guest OS 31-2 to the reception side guest OS 31-1. As a result of this change (transfer), the total amount of CPU allocation scheduled time to the reception-side guest OS 31-1 from the reception interrupt point to the most recently confirmed schedule position is increased by 2 ms.

  After executing step S74, the guest OS scheduler 221 proceeds to step S75. On the other hand, if the determination in step S73 is no, the guest OS scheduler 221 skips step S74 and proceeds to step S75. Even if the determination in step S73 is NO, if the most recently confirmed schedule position is a dispatch scheduled position where the CPU time is allocated to the reception-side guest OS 31-1, the latest position from the reception interrupt point is most recently determined. The total amount of CPU allocation scheduled time for the reception-side guest OS 31-1 up to the confirmed schedule position increases by 2 ms.

  In step S75, the guest OS scheduler 221 confirms the next schedule position in the CPU time allocation table 222. Then, the guest OS scheduler 221 performs the processing from step S72 onward in the same manner as when the current schedule position is confirmed in step S71.

  That is, the guest OS scheduler 221 determines whether or not the total amount of CPU allocation scheduled time for the receiving guest OS 31-1 as described above is still insufficient with respect to the time required for the reception processing of the guest OS 31-1. (Step S72).

  If the total amount of scheduled CPU allocation time for the receiving guest OS 31-1 as described above is insufficient (step S72), the guest OS scheduler 221 determines the most recently confirmed schedule position, that is, step It is determined whether or not the next schedule position confirmed in S75 is a schedule position where CPU time is allocated to the transmission side guest OS 31-2 (step S73). If the determination in step S73 is yes, the guest OS scheduler 221 changes the next schedule position confirmed in step S75 for the reception-side guest OS 31-1 (step S74). Then, steps S75 and S72 are performed again. On the other hand, if the determination in step S73 is no, step S74 is skipped and steps S75 and S72 are performed again.

  Eventually, if the total amount of the CPU allocation scheduled time for the receiving guest OS 31-1 as described above becomes equal to or longer than the time required for the receiving process of the guest OS 31-1 (step S72), the guest OS scheduler 221 is executed. Ends the schedule adjustment process according to the flowchart of FIG.

  As described above, in the present embodiment, based on the CPU time allocation table 222, guest OSes scheduled to be allocated (scheduled to be dispatched) after the occurrence of the reception interrupt are sequentially checked and allocated to the sending guest OS 31-2. Processing for changing the scheduled CPU time for the receiving guest OS 31-1 until the total CPU time (scheduled CPU allocation time) to be allocated to the guest OS 31-1 after the occurrence of the reception interrupt exceeds 4 ms. repeat.

  FIG. 13 shows an example of the schedule before and after adjustment when the schedule for the guest OSs 31-1 and 31-2 of the guest OSs 31-1 to 32-3 is adjusted according to the procedure shown in the flowchart of FIG. .

  Assume that communication from the guest OS 31-2 to the guest OS 31-1 is performed immediately after time t20 in FIG. 13A, that is, immediately after the time t20 at which the CPU time is allocated to the guest OS 31-2. The interrupt management unit 23 of the VMM 20 generates a reception interrupt for the communication between guest OSs to the reception-side guest OS 31-1 at time t20. Then, the guest OS scheduler 221 adjusts the schedule indicated by the CPU time allocation table 222 as follows.

  First, the guest OS 31-2 to which the 2 ms CPU time (that is, the CPU time at the current schedule position) up to the time t21 immediately after the interruption time (current time) t20 is assigned is the sending guest OS. In this case, the CPU time of 2 ms from the time point t20 to the time point t21 is changed from the transmission side guest OS 31-2 to the reception side guest OS 31-1, as indicated by the arrow 130.

  The next 2 ms CPU time from time t21 to time t22 is scheduled for the guest OS 31-3. The guest OS 31-3 has nothing to do with the inter-guest OS communication between the guest OS 31-2 and the guest OS 31-1. For this reason, schedule adjustment is not performed regarding the CPU time scheduled for the guest OS 31-3.

  The CPU time of 2 ms from the next time point t22 to the time point t23 is originally scheduled for the reception-side guest OS 31-1. Therefore, including the CPU time of 2 ms at the corresponding schedule position from time t22 to time t23, the CPU scheduled to be assigned to the receiving guest OS 31-1 by time t23 when 6 ms elapses from the interrupt time (current time) t20. The total time satisfies 4 ms required for the reception process immediately after the interrupt process in the receiving guest OS 31-1. In this case, the schedule adjustment ends.

  In the schedule adjustment according to the third modified example, the CPU time additionally allocated to the receiving guest OS 31-1 is not continuous. However, since CPU time is allocated to the receiving guest OS 31-1 prior to the transmitting guest OS 31-2 that performs inter-guest OS communication with the receiving guest OS 31-1, there is generally no problem.

  In the third modified example, as in the second modified example, for simplification of description, transfer is performed in the CPU time unit that is originally allocated to the guest OSs 31-1 to 31-3 (guests to be allocated). (OS change) is assumed to be performed. However, the reception interrupt generally occurs in the middle of the CPU time allocated to the guest OS being executed. In addition, the CPU time allocated to each guest OS may be different for each guest OS. In such a case, the guest OS scheduler 221 may adjust the schedule by dividing the CPU time scheduled to be assigned to each guest OS into a necessary amount of time (for example, the minimum time unit managed by the guest OS scheduler 221). .

  In addition, this invention is not limited to the said embodiment or its modification example as it is, A component can be deform | transformed and embodied in the range which does not deviate from the summary in an implementation stage. In addition, various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the embodiment or its modification. For example, you may delete a some component from all the components shown by embodiment or its modification.

1 is a block diagram showing a configuration of a virtual machine system according to an embodiment of the present invention. The figure which shows the example of a schedule represented by CPU time allocation table. The figure which shows the data structure example of a guest OS context. The figure for demonstrating the problem of the schedule represented by CPU time allocation table The figure which shows the example of the schedule represented by the CPU time allocation table after a change. 6 is a flowchart showing a procedure of schedule adjustment processing in the embodiment. 5 is a flowchart showing a processing procedure for optimizing the system in a situation where the first type of communication is performed in the embodiment. 7 is a flowchart showing a processing procedure for optimizing the system in a situation where the second type of communication is performed in the embodiment. 9 is a flowchart showing a procedure for temporary CPU additional allocation time designation of the reception-side guest OS by the transmission-side guest OS and schedule adjustment based on the designation, which is applied in the first modification of the embodiment. 9 is a flowchart showing a procedure for schedule adjustment applied in a second modification of the embodiment. The figure which shows the example of the schedule before and behind adjustment when a schedule is adjusted according to the procedure which the flowchart of FIG. 10 shows. 9 is a flowchart showing a procedure for schedule adjustment applied in a third modification of the embodiment. The figure which shows the example of the schedule before and behind adjustment when a schedule is adjusted according to the procedure which the flowchart of FIG. 12 shows.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... Physical computer, 10 ... Hardware (HW), 11 ... CPU (real CPU), 20 ... Virtual computer manager (VMM), 21 ... Communication management part between guest OSs, 22 ... Guest OS execution management part, 23 ... Interrupt Management unit, 24 ... Guest OS context management unit, 210 ... Guest OS communication IF, 211 ... Guest OS communication monitoring unit, 221 ... Guest OS scheduler, 222 ... CPU time allocation table, 223 ... Dispatcher, 240 ... CPU additional allocation Time setting unit, 241-1 to 241-3 ... guest OS context, 242 ... guest OS specific data, 243 ... interrupt factor register, 244 ... CPU additional allocation time information.

Claims (12)

In a virtual machine system in which a plurality of guest OSs are executed in a time-sharing manner in a virtual machine execution environment provided by a virtual machine manager that operates on a physical machine including a CPU,
The virtual machine manager is
Interrupt management means for managing an interrupt to an arbitrary guest OS among the plurality of guest OSs, wherein a request for inter-guest OS communication from the sending guest OS to the receiving guest OS is given to the virtual machine manager. An interrupt management means for notifying the reception guest OS by reception interrupt of reception of the communication between the guest OSs in the reception guest OS ;
A scheduler for managing a schedule for executing the plurality of guest OSs in a time-sharing manner, wherein an interrupt factor to an arbitrary guest OS among the plurality of guest OSs occurs, and the factor is the guest OS In the case of reception of inter-communication, the virtual machine manager cancels the reception interrupt after the interrupt processing, with the arbitrary guest OS as the reception guest OS, and the reception guest OS performs a predetermined interrupt processing. A scheduler that adjusts the schedule so that the CPU time required for the reception process performed by the receiving guest OS itself is additionally allocated to the receiving guest OS,
A virtual machine system comprising: a dispatcher that dispatches the plurality of guest OSs according to the schedule adjusted by the scheduler. The interrupt management means, before notifying the reception side guest OS of the reception of the communication between the guest OSs by a reception interrupt, the guest in the interrupt factor register included in the guest OS context specific to the reception side guest OS Set the inter-OS communication receive bit to the first state,
The interrupt processing performed by the receiving guest OS confirms the interrupt factor based on the first state of the inter-guest OS communication receiving bit, and the receiving guest OS transmits the inter-guest OS communication receiving bit. The virtual computer system according to claim 1 , further comprising a process of setting to a second state different from the first state . The virtual machine manager is
In each guest OS context of the plurality of guest OSes, in addition to the inter-guest OS communication reception bit, a CPU time value necessary for reception processing after the reception interrupt is canceled is set as a CPU additional allocation time setting value. A guest OS context management means for managing a guest OS context including:
A guest OS communication monitoring means for observing communication throughput by monitoring communication between guest OSes;
Based on the guest OS communication monitoring means according to the communication throughput observations, corresponding to the guest OS and a CPU additional allocation time setting means for changing the CPU additional allocation time setting value included in the specific of the guest OS context In addition,
The scheduler adjusts the schedule based on a CPU additional allocation time setting value required for reception processing after reception interrupt cancellation included in the guest OS context specific to the receiving guest OS.
Virtual computer system according to claim 2, wherein the this.   2. The scheduler adjusts the schedule so that an allocation amount of CPU time for each of the plurality of guest OSs is kept constant before and after schedule adjustment in a specific time zone. Virtual computer system.   When the second time zone scheduled to be assigned to another guest OS is included in the first time zone in which the CPU time is additionally assigned to the reception-side guest OS, the scheduler includes the second time zone. 5. The virtual machine system according to claim 4, wherein the virtual machine system is replaced with a third time zone scheduled to be assigned to the receiving guest OS after the first time zone.   The virtual machine system according to claim 1, wherein the scheduler allocates a CPU time scheduled to be allocated to the transmitting guest OS to a CPU time additionally allocated to the receiving guest OS. In a virtual machine system in which a plurality of guest OSs are executed in a time division in a virtual machine execution environment provided by a virtual machine manager that operates on a physical computer including a CPU, the plurality of guest OSs are executed in a time division manner A schedule adjustment method for adjusting a schedule,
Upon receiving a request for inter-guest OS communication from the sending guest OS to the receiving guest OS given to the virtual machine manager, the virtual machine manager receives the reception of the inter-guest OS communication in the receiving guest OS. A step of notifying the receiving guest OS by interruption;
When an interrupt factor to an arbitrary guest OS among the guest OSs occurs, the inter-guest OS communication in the arbitrary guest OS is caused by the inter-guest OS communication from the sending guest OS. The virtual machine manager determining whether it is received,
The virtual machine manager adjusting the schedule with the arbitrary guest OS as the receiving guest OS when the interrupt factor to the arbitrary guest OS is reception of communication between guest OSes , After the receiving guest OS performs predetermined interrupt processing and notifies the virtual machine manager of the cancellation of the receiving interrupt after the interrupt processing, the CPU time required for the receiving processing performed by the receiving guest OS itself The virtual machine manager adjusts the schedule so as to be additionally assigned to the receiving guest OS. A schedule adjustment method comprising: In the notifying step, the virtual machine manager is managed by a guest OS context management unit included in the virtual machine manager before notifying the reception guest OS of reception of the communication between guest OSs by a reception interrupt. Set the guest OS communication reception bit in the interrupt factor register included in the guest OS context unique to the receiving guest OS among the guest OS contexts of the plurality of guest OSs to the first state,
The interrupt processing performed by the receiving guest OS confirms the interrupt factor based on the first state of the inter-guest OS communication receiving bit, and the receiving guest OS transmits the inter-guest OS communication receiving bit. The schedule adjustment method according to claim 7 , further comprising a process of setting a second state different from the first state . The guest OS context includes, in addition to the guest OS communication reception bit, a CPU time value necessary for reception processing after the reception interrupt is canceled as a CPU additional allocation time setting value,
The schedule adjustment method is:
The virtual machine manager observing communication throughput by monitoring communication between guest OSes;
Based on said communication throughput observations, further comprising the step of corresponds to the guest OS to specific the guest OS context included the CPU additional allocation time values that are the virtual machine manager to change,
In the adjusting step, the virtual machine manager is based on the CPU additional allocation time setting value necessary for reception processing after the reception interrupt is released, which is included in the guest OS context specific to the receiving guest OS. , Adjust the schedule
Scheduling method of claim 8, wherein the this. In the adjusting step, the virtual machine manager changes the schedule so that an allocated amount of CPU time for each of the plurality of guest OSs is kept constant before and after the schedule adjustment in a specific time zone. The schedule adjustment method according to claim 7, wherein:   In the adjusting step, the virtual machine manager includes a second time zone scheduled to be assigned to another guest OS in a first time zone in which CPU time is additionally assigned to the receiving guest OS. The schedule adjustment method according to claim 10, wherein the second time zone and a third time zone scheduled to be allocated to the receiving guest OS after the first time zone are switched.   8. The virtual machine manager according to claim 7, wherein in the adjusting step, the virtual machine manager allocates a CPU time scheduled to be allocated to the transmitting guest OS to a CPU time additionally allocated to the receiving guest OS. Schedule adjustment method.

Images