A Deterministic Scheduling Method for an Embedded Container Operating System

Abstract

The present invention belongs to the technical field of computer system software, and particularly relates to a deterministic scheduling method for an embedded container operating system, which ensures that multiple container applications can obtain the required quota of CPU computing resources during operation on an embedded operating system platform. The implementation of this method includes the following steps: 1. Expand the predictable computing resource quota control layer on the global SMP scheduling mode of the RTOS to support the allocation of determined computing resources for containers. 2. The CPU core resource pool management module resident in the container engine is responsible for maintaining the idle and occupancy status of each CPU core of the hardware platform. 3. The cpuset control module and the time quota monitoring and control module resident in the operating system kernel are respectively used for control during scheduling in the scenarios of exclusive CPU cores and shared CPU cores.

Description

Technical Field

[0001] The present invention belongs to the technical field of computer system software, and particularly relates to a deterministic scheduling method for an embedded container operating system. Background Art

[0002] Resource limitation, as a key technology in container virtualization, is responsible for restricting the use of container resources, which can effectively prevent the computing resources of the host from being unrestrictedly used by a certain container, resulting in resource starvation for other containers. Embedded containers utilize a resource quota management mechanism to achieve the ability to limit computing resources. When a container is dynamically deployed, it needs to obtain the CPU computing resources required during its operation according to the configuration description. On the one hand, it is necessary to determine whether the current node has sufficient resources to meet the operation of the container. On the other hand, it is necessary to prevent a certain container from consuming CPU resources infinitely when a failure occurs on the host, resulting in the inability of other containers to run. Summary of the Invention

[0003] In view of this, the present invention provides a deterministic scheduling method for an embedded container operating system, which extends a predictable computing resource quota control layer on the global SMP scheduling mode of the RTOS to enable it to support allocating deterministic computing resources for containers. By extending the core set scheduling mechanism and the time quota monitoring scheduling mechanism, the resource quota binding of containers with "1 / N-M" cores can be achieved, and multiple container applications can obtain the required quota of CPU computing resources during their operation.

[0004] To achieve the above technical objectives, the specific technical solutions adopted by the present invention are as follows:

[0005] A deterministic scheduling method for an embedded container operating system, which extends a predictable computing resource quota control layer on the global SMP scheduling mode of the RTOS to enable the scheduling framework to support allocating deterministic computing resources for containers;

[0006] The corresponding relationships between containers and CPU cores include three categories: one-to-one, one-to-N, and N-to-one;

[0007] For one-to-one and one-to-N, a container exclusively occupies a determined number of CPU cores; for N-to-one, multiple containers share CPU cores, but each container has a determined time ratio;

[0008] Configure the CPU core resource pool management module resident in the container engine to maintain the idle and occupancy status of each CPU core on the hardware platform; configure the cpuset control module and the time quota monitoring control module to control the scheduling in scenarios for exclusive cores and shared CPU cores respectively.

[0009] Further, the cpuset control module enables the container to implement the scheduling for an application to exclusively occupy 1 - N CPU cores. By extending the SMP scheduling method of the RTOS, the full - core scheduling of the hardware platform is controlled within the core set configured for the container, supporting the container to be scheduled and run on the determined integer cores, and the integer set is 1 - N.

[0010] Further, in the case of private exclusive cores, the CPU core resource management module where the container engine resides dynamically maintains the idle / busy status of each core on the hardware platform, and updates the core status when creating and deleting containers; the cpuset control module resident in the kernel maintains the exclusive core set information for each container.

[0011] Further, during global SMP scheduling, after the currently running core selects the highest - priority ready task from the ready chain, the cpuset control module checks whether the current core is within the cpuset core set of the container to which the selected task belongs. If it is, it directly participates in the scheduling; if not, it notifies the cores within the core set to perform scheduling through an inter - core interrupt.

[0012] Further, the time quota monitoring and control module is used to implement the scheduling for container applications to share one CPU core; in the scenario where multiple application containers share a CPU core, based on the time quota monitoring and control module, tasks of each container can have the opportunity to run within a certain time period.

[0013] Further, the time quota monitoring and control module controls each container to occupy or release the CPU execution right according to the time proportion of each container within the monitoring period.

[0014] Further, in the case of shared cores, the time monitoring and control module resident in the kernel maintains the time schedule, the main time frame, and the running status for each core required to share the operation.

[0015] Further, the CPU core resource management module checks whether the remaining computing resources of the core required to run meet the requirements according to the maintained core resource information of each core and the proportion of the main time frame required by the container. If it meets the requirements, it creates a corresponding time window for the container and adds it to the time schedule of the core required to run. Until the last container running on this core is successfully created, each time window rotates normally; if all the running containers do not fully occupy this CPU core, idle windows are reserved to participate in the rotation.

[0016] Further, when deleting a container, the time window to which the container belongs is deleted, and the time proportion of the deleted container is allocated to the idle window to participate in the rotation; when a new container is added, it is judged whether there is still remaining resource in the monitoring period of the CPU core to be shared. If not, the creation of this container fails; if so, the time proportion required by this container is divided from the idle window to create the time window to which it belongs to participate in the rotation scheduling.

[0017] With the above technical solution, the present invention can bring the following beneficial effects:

[0018] After implementing the method of the present invention, the extended core set scheduling mechanism and the time quota monitoring scheduling mechanism can achieve the binding of the resource quota between the container and "1 / N-M" cores, solving the problem that the quota management of CPU resources for IT containers is a quota control based on the SMP symmetric multi-processing mode, and the CPU execution time interval obtained by the container lacks cycle certainty and the accuracy of the specific time interval. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present disclosure. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0020] Figure 1 It is a deterministic scheduling framework diagram for an embedded container operating system

[0021] Figure 2 It is a schematic diagram of cpuset control scheduling under exclusive CPU cores;

[0022] Figure 3 It is a schematic diagram of time ratio quota monitoring control under shared CPU cores. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0023] The embodiments of the present disclosure will be described in detail below with reference to the drawings.

[0024] The following illustrates the implementation manners of the present disclosure through specific specific examples. Those skilled in the art can easily understand other advantages and effects of the present disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all the embodiments. The present disclosure can also be implemented or applied through other different specific implementation manners. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present disclosure. It should be noted that, without conflict, the following embodiments and the features in the embodiments can be combined with each other. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present disclosure without creative efforts belong to the scope of protection of the present disclosure.

[0025] Note that the following description relates to various aspects of embodiments within the scope of the appended claims. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of the aspects set forth herein can be used to implement a device and / or practice a method. Additionally, this device can be implemented and this method can be practiced using other structures and / or functionality in addition to one or more of the aspects set forth herein.

[0026] It should also be noted that the diagrams provided in the following embodiments only illustrate the basic concept of the present disclosure schematically. The diagrams only show the components related to the present disclosure, rather than being drawn according to the number, shape, and size of the components in actual implementation. The type, quantity, and ratio of each component in actual implementation can be arbitrarily changed, and the component layout type may also be more complex.

[0027] In addition, in the following description, specific details are provided to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0028] In one embodiment of the present invention, refer to Figures 1 - 3 A deterministic scheduling method for an embedded container operating system is proposed. A predictable computing resource quota control layer is extended on the global SMP scheduling mode of the RTOS, so that the scheduling framework supports allocating deterministic computing resources for containers;

[0029] The corresponding relationships between containers and CPU cores include three categories: one-to-one, one-to-N, and N-to-one;

[0030] For one-to-one and one-to-N, a container exclusively occupies a determined number of CPU cores; for N-to-one, multiple containers share CPU cores, but each container has a determined time share;

[0031] Configure the CPU core resource pool management module residing in the container engine to maintain the idle and occupancy status of each CPU core of the hardware platform; configure the cpuset control module and the time quota monitoring and control module to perform control during scheduling in scenarios for exclusive cores and shared CPU cores respectively.

[0032] In this embodiment, the cpuset control module

[0033] The implementation container is used to implement the scheduling of an application to exclusively occupy 1-N CPU cores. By extending the SMP scheduling method of the RTOS, the full-core scheduling of the hardware platform is controlled within the core set configured for the container, supporting the container to be scheduled and run on a determined integer number of cores, where the integer set is 1-N.

[0034] In this embodiment, in the case of private exclusive cores, the CPU core resource management module resident in the container engine dynamically maintains the idle / busy status of each core of the hardware platform, and updates the core status when creating and deleting a container; the cpuset control module resident in the kernel maintains exclusive core set information for each container.

[0035] In this embodiment, during global SMP scheduling, after the currently running core selects the highest-priority ready task from the ready queue, the cpuset control module checks whether the current core is within the cpuset core set of the container to which the selected task belongs. If it is, it directly participates in the scheduling; if not, it notifies the cores within the core set to perform scheduling through an inter-core interrupt.

[0036] In this embodiment, the time quota monitoring and control module is used to implement the scheduling of container applications to share one CPU core; in the scenario where multiple application containers share a CPU core, based on the time quota monitoring and control module, tasks of each container can have the opportunity to run within a certain time period.

[0037] In this embodiment, the time quota monitoring and control module controls each container to occupy or release the CPU execution right within the monitoring period according to the time ratio of each container within the monitoring period.

[0038] In this embodiment, in the case of shared cores, the time monitoring and control module resident in the kernel maintains a schedule table, a main time frame, and a running status for each core that requires shared operation.

[0039] In this embodiment, the CPU core resource management module checks whether the computing resource margin of the core required to run meets the requirement according to the maintained core resource information of each core and the ratio of the main time frame required by the container. If it meets the requirement, it creates a corresponding time window for the container and adds it to the schedule table of the core required to run. Until the last container running on this core is successfully created, each time window rotates normally; if all the running containers do not occupy the entire CPU core, idle windows are reserved to participate in the rotation.

[0040] In this embodiment, when deleting a container, the time window belonging to the container is deleted, and the time ratio of the deleted container is allocated to the idle window to participate in the rotation; when a new container is added, it is judged whether there is still resource margin in the monitoring period of the CPU core to be shared. If not, the creation of the container fails; if so, the time ratio required by the container is allocated from the idle window to create the time window belonging to it to participate in the rotation scheduling.

[0041] The time quota monitoring and control module in this embodiment is used to implement the scheduling for container applications to share a CPU core. In the scenario where multiple application containers share a CPU core, in order to prevent a container from occupying CPU computing resources for a long time, which may cause other container applications to be unable to obtain the CPU execution right in time and affect their normal functions, a time quota monitoring and control module is designed to ensure that the tasks of each container can have the opportunity to run within a certain period of time. Although the traditional time table scheduling mode can also meet the above requirements, it needs to build a complete time window scheduling table for the CPU core before the system runs, and statically determine the application name and the duration of the time window, which does not conform to the dynamic running characteristics of containers. The time quota monitoring and control module controls each container to occupy or release the CPU execution right according to the time ratio of each container within the monitoring period.

[0042] In the case of sharing cores, the CPU core resource management module resident in the container engine dynamically maintains whether each core of the hardware platform is idle and the remaining resources, and updates the remaining resources when creating and deleting containers. The time monitoring and control module resident in the kernel maintains information such as the time table, the main time frame (monitoring period), and the running status for each core that requires shared operation.

[0043] The CPU core resource management module checks whether the remaining computing resources of the core required to run meet the requirements according to the maintained core resource information of each core and the ratio of the main time frame required by the container. If it meets the requirements, a corresponding time window is created for the container and added to the time table of the core required to run. Until the last container running on this core is successfully created, each time window rotates normally. If all the running containers do not occupy the CPU core completely, idle windows are reserved to participate in the rotation.

[0044] Due to the dynamic running nature of containers, a certain container may be deleted or a new container may be added during the running process. Both of these situations require re-adjusting the time table. When deleting a container, the time window to which the container belongs is deleted, and the time ratio of the deleted container is allocated to the idle window to participate in the rotation; when adding a new container, it is judged whether there is still remaining resources in the monitoring period of the CPU core to be shared. If not, the creation of this container fails. If it meets the requirements, the time ratio required by this container is allocated from the idle window to create the time window to which it belongs and participate in the rotation scheduling.

[0045] The main process of the scheduling method for exclusive use of a CPU core in this embodiment is described as follows:

[0046] 1) Determine the set of cores exclusive to the container: The following options are supported when running a container to determine the CPU computing resources occupied by the container:

[0047] --cpus: The number of cores exclusive to this container;

[0048] --cpuset: The set of cores exclusively used by this container.

[0049] Choose one of the above two options. The CPU core resource management module will finally convert the cpus option into the cpuset option. When the number of exclusive cores is configured, the corresponding number of core sets will be allocated according to the idle status of the cores; when the exclusive core set is configured, the CPU core resource management module checks whether the required core set is idle. If it is idle, it is directly allocated for exclusive operation by this container.

[0050] 2) Extended core set control scheduling: During global SMP scheduling, after the currently running core selects the highest-priority ready task from the ready queue, the cpuset control module checks whether the current core is within the cpuset core set of the container to which the selected task belongs. If it is, it directly participates in the scheduling; if not, it notifies the cores within the core set to perform scheduling through inter-core interrupts.

[0051] The main process of the scheduling method for shared CPU cores is described as follows:

[0052] 1) Determine the monitoring period of the running CPU core, that is, the main time frame: Describe the minimum period of all periodic tasks in this application in the dockerfile of the container image. The orchestration and scheduling system obtains the minimum periods of each container deployed on the same core, and takes the greatest common divisor of the minimum periods as the monitoring period of this core, and sends it to the specified physical node along with the command to start the first container.

[0053] 2) Build the initial dynamic time schedule: When creating a container, determine that multiple containers share the CPU core according to the parameter options. The options include:

[0054] --cpuset: The set of CPU cores on which this container runs in a shared manner;

[0055] --cpuquota: The proportion of the main time frame (monitoring period) occupied by this container on the shared cores;

[0056] -f: Indicates whether this container is the last container to be started, that is, it indicates the timing when the time schedule is enabled.

[0057] The first two options must be specified, and the third option only needs to be specified when initially creating the time schedule. The default value is false.

[0058] 3) The CPU core resource management module checks whether the remaining computing resources of the required running core meet the requirements according to the maintained core resource information of each core and the proportion of the main time frame required by this container. If it meets the requirements, create the corresponding time window for this container and add it to the time schedule of the required running core. After the last container running on this core is successfully created, each time window rotates normally. If all the running containers do not fully occupy this CPU core, reserve the idle window to participate in the rotation.

[0059] 4) Runtime refactoring schedule: Due to the runtime dynamics of the container, a certain container may be deleted or a new container may be added during the runtime. In both cases, the schedule needs to be readjusted. When deleting a container, the time window to which the container belongs is deleted, and the time percentage of the deleted container is allocated to the idle window for rotation; when adding a new container, it is judged whether there is still resource margin in the monitoring period of the CPU core to be shared. If not, the creation of the container fails. If so, the time percentage required by the container is allocated from the idle window to create the time window to which it belongs for round-robin scheduling.

[0060] As described above, it is only the specific implementation manner of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any changes or substitutions that can be easily thought of by those skilled in the art within the technical scope disclosed by the present disclosure should be covered by the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be subject to the protection scope of the claims.

Claims

1. A deterministic scheduling method for an embedded container operating system, characterized in that Expand the predictable computing resource quota control layer on the global SMP scheduling method of RTOS to enable the scheduling framework to support allocating deterministic computing resources to containers; The corresponding relationships between containers and CPU cores include three types: one-to-one, one-to-N, and N-to-one; For one-to-one and one-to-N, the container exclusively occupies a determined number of CPU cores; for N-to-one, multiple containers share CPU cores, but each container has a determined time share; Configure the CPU core resource pool management module resident in the container engine to maintain the idle and occupancy status of each CPU core on the hardware platform; configure the cpuset control module and the time quota monitoring and control module to perform control during scheduling in scenarios for exclusive cores and shared CPU cores respectively. Among them, the cpuset control module realizes the scheduling for the container to exclusively use 1 - N CPU cores. By expanding the SMP scheduling method of RTOS, the full-core scheduling of the hardware platform is controlled within the core set configured for the container, supporting the container to be scheduled and run on determined integer cores, and the integer set is 1 - N; In the case of shared cores, the time monitoring and control module resident in the kernel maintains a schedule table, a main time frame, and a running status for each core requiring shared operation. The CPU core resource management module checks whether the remaining computing resources of the core requiring operation meet the requirements based on the maintained core resource information of each core and the proportion of the main time frame required by the container. If it meets the requirements, a corresponding time window is created for the container and added to the schedule table of the core requiring operation. Until the last container running on this core is successfully created, each time window rotates normally; if all the running containers do not fully occupy this CPU core, an idle window is reserved to participate in the rotation.

2. The deterministic scheduling method of the embedded container operating system according to claim 1, characterized in that In the case of private exclusive cores, the CPU core resource management module resident in the container engine dynamically maintains the idle / busy status of each core on the hardware platform and updates the core status when creating and deleting containers; the cpuset control module resident in the kernel maintains exclusive core set information for each container.

3. The deterministic scheduling method of the embedded container operating system according to claim 2, characterized in that, During global SMP scheduling, after the currently running core selects the highest-priority ready task from the ready chain, the cpuset control module checks whether the current core is within the cpuset core set of the container to which the selected task belongs. If it is, it directly participates in the scheduling; if not, it notifies the cores within the core set to perform scheduling through an inter-core interrupt.

4. The deterministic scheduling method of the embedded container operating system according to claim 3, characterized in that, The time quota monitoring and control module is used to realize the scheduling for container applications to share a CPU core; in the scenario where multiple application containers share a CPU core, based on the time quota monitoring and control module, the tasks of each container can have the opportunity to run within a certain time period.

5. The deterministic scheduling method of the embedded container operating system according to claim 4, wherein The time quota monitoring and control module controls each container to occupy or release the CPU execution right within the monitoring period according to the time proportion of each container within the monitoring period.

6. The deterministic scheduling method of the embedded container operating system according to claim 5, wherein When deleting a container, delete the time window to which the container belongs and divide the time proportion of the deleted container to the idle window to participate in the rotation; when a new container is added, judge whether there is still remaining resource in the monitoring period of the CPU core to be shared. If not, the creation of this container fails; if so, divide the time proportion required by this container from the idle window to create the time window to which it belongs to participate in the rotation scheduling.

Images