Resource control device, resource control method, and program

Abstract

A resource control device according to the present invention realizes a system that consistently and stably performs CPU resource allocation in accordance with uniform rules: by detecting a change in any one of a file indicating a list of CPU cores that are actually allocated to each of a plurality of groups set regarding program operation units, a file indicating the groups with which the operation units are actually affiliated, and a file indicating an actual correspondence relationship between delegator groups and delegated groups regarding the authority to allocate the CPU cores to the operation units in accordance with the groups; by determining, regarding the contents of a changed file, whether there is a violation with respect to a first rule that prescribes a list of CPU cores to be allocated to the respective groups, a second rule that prescribes the classifications of the operation units that can be affiliated with the respective groups, and a third rule that prescribes the correspondence relationship between the delegator groups and the delegated groups regarding the authority to allocate the CPU cores to the operation units; and by executing processing set with respect to violated rules.

Description

Technical Field

[0004] ,

[0002] , , , , , , , , , ,

[0003] ,

[0001] The present invention relates to a resource control device, a resource control method, and a program.

Background Art

[0002] Conventionally, efforts have been made on Cyber-Physical System (CPS) that collects sensor information of the real world (physical system) and analyzes the collected information in the cyber space, and utilizes it for system control of the real world and data circulation between systems.

[0003] In CPS, the physical system that was locally closed is separated into an actuator and control logic, and the control logic is arranged at a remote edge. In order to perform (periodic) control from the control logic across the network, it is essential to guarantee the (period) of the "total processing time (TAT)" required for a series of processes of (1) control operation, (2) control instruction signal, (3) remote control, and (4) control result signal. For this purpose, it is necessary to suppress jitter in the entire system, including both calculation processing and communication processing that lead to jitter in the period. Jitter is roughly divided into two factors: control logic and communication jitter, and it is necessary to suppress both jitters. In particular, since the control logic is executed using computing resources, stable resource allocation is required.

Prior Art Documents

Non-Patent Documents

[0004]

Non-Patent Document 1

[0005] However, in server infrastructure providing services such as IaaS / PaaS / SaaS, multitasking operating systems, such as Linux® OS (Operating System), have the following problems:

[0006] (1) Multiple APIs are provided for managing CPU core resources (hereinafter referred to as "CPU resources"), and there is no unified control API. For example, there are two mechanisms, set_schedaffinity and cgroup. For example, an application (hereinafter referred to as "app") can use set_schedaffinity to change the allocation of CPU resources, and then use the cgroup API to change that allocation again, and the previous state is not managed by the OS.

[0007] (2) In addition to (1), there is no mechanism for the OS to uniformly manage the CPU resources allocated to each application (that is, the management of CPU resources is left to the administrator, and the OS does not support this function).

[0008] (3) After allocating the desired CPU resources to each application, the OS lacks a management function to maintain and continue that state (i.e., the CPU resource administrator responsible for the system must guarantee the allocation of CPU resources).

[0009] As a result of the above (1) to (3), there is a problem in that the resource settings are intentionally changed after resource allocation, making it impossible to allocate resources stably and thus preventing the application from stabilizing its processing. The present invention has been made in view of the above points, and aims to realize a mechanism that consistently and stably allocates CPU resources according to a unified rule. [Means for solving the problem]

[0010] Therefore, in order to solve the above problems, the present invention provides a resource control device comprising: a first detection unit that detects changes to any of the following: a first file which stores information indicating a list of CPU cores actually allocated to each of a plurality of groups set with respect to the operating units of a program; a second file which stores information indicating the group to which each of the operating units actually belongs; and a third file which stores information indicating the actual correspondence between the group that delegates the authority to allocate CPU cores to the operating units by the group; and when the first detection unit detects a change in any of the files, the first detection unit detects changes in the modified file. The system includes a determination unit that determines whether there is a violation of a first rule that defines a list of CPU cores to be assigned to each of the aforementioned groups, a second rule that defines the types of operating units that can belong to each of the aforementioned groups, or a third rule that defines the correspondence between the group that delegates the authority to assign CPU cores to the aforementioned operating units and the group to which the authority is delegated, and a first processing execution unit that, if the determination unit determines that there is a violation, executes the processing set for violations of the first rule, the processing set for violations of the second rule, and the processing set for violations of the third rule that corresponds to the violation. The type of the operating unit is distinguished by whether or not it is a kernel thread, whether or not it is a user process, whether or not it is the operating unit relating to a specific program name, or whether or not it is the operating unit that violates any of the first, second, or third rules. . [Effects of the Invention]

[0011] This enables the implementation of a system that consistently and stably allocates CPU resources according to a unified set of rules. [Brief explanation of the drawing]

[0012] [Figure 1] This figure shows an example of the hardware configuration of the resource control device 10 in an embodiment of the present invention. [Figure 2] This is a diagram to explain the cgroup mechanism. [Figure 3] This figure shows an example of the functional configuration of the resource control device 10 in an embodiment of the present invention. [Figure 4]It is a flowchart for explaining an example of the overall processing flow executed by the resource control device 10. [Figure 5] It is a flowchart for explaining an example of the processing procedure of the resource group rule file analysis / setting preparation process (S101). [Figure 6] It is a diagram showing a configuration example of the resource group rule file r1. [Figure 7] It is a flowchart for explaining an example of the processing procedure of the preparation process for detecting a belonging rule violation. [Figure 8] It is a flowchart for explaining an example of the processing procedure of the preparation process for detecting an allocation rule violation. [Figure 9] It is a flowchart for explaining an example of the processing procedure of the preparation process for detecting a privilege delegation rule violation. [Figure 10] It is a flowchart for explaining an example of the system call rule file analysis / setting preparation process (S102). [Figure 11] It is a diagram showing a configuration example of the system call rule file r2. [Figure 12] It is a flowchart for explaining an example of the processing procedure of the preparation completion confirmation process (S103). [Figure 13] It is a flowchart for explaining an example of the processing procedure of the event waiting process. [Figure 14] It is a flowchart for explaining an example of the processing procedure of the processing according to the file status change. [Figure 15] It is a flowchart for explaining an example of the processing procedure of the processing when cgroup.procs is changed. [Figure 16] It is a flowchart for explaining an example of the processing procedure of the processing when cpuset.cpus is changed. [Figure 17] It is a flowchart for explaining an example of the processing procedure of the processing when cgroup.subtree_control is changed. [Figure 18]This flowchart illustrates an example of the processing procedure for handling system call invocations. [Modes for carrying out the invention]

[0013] Embodiments of the present invention will be described below with reference to the drawings. Figure 1 is a diagram showing an example of the hardware configuration of a resource control device 10 in an embodiment of the present invention. The resource control device 10 in Figure 1 includes a drive device 100, an auxiliary storage device 102, a memory device 103, one or more CPUs 104, and an interface device 105, etc., which are all interconnected by bus B.

[0014] The program that enables processing in the resource control device 10 is provided on a recording medium 101 such as a CD-ROM. When the recording medium 101 containing the program is set in the drive device 100, the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100. However, the program does not necessarily have to be installed from the recording medium 101; it may also be downloaded from another computer via a network. The auxiliary storage device 102 stores the installed program as well as necessary files and data.

[0015] When a program startup command is received, the memory device 103 reads the program from the auxiliary storage device 102 and stores it. The CPU 104 executes the functions related to the resource control device 10 according to the program stored in the memory device 103. In this embodiment, one or more CPUs 104 include multiple CPU cores. The interface device 105 is used as an interface for connecting to a network.

[0016] In this embodiment, the resource control device 10 utilizes the cgroup mechanism, which is one method of CPU core resource management in Linux (registered trademark).

[0017] Figure 2 is a diagram illustrating the cgroup mechanism. A cgroup is a mechanism for managing resources such as memory and network, as well as CPU core resources. In a cgroup, a process / thread group is defined for each node in a tree structure, and resource allocation is controlled on a unit basis (cgroup).

[0018] In the tree structure shown in Figure 2, rounded rectangles with dashed borders correspond to directories. A given cgroup corresponds to one directory, and the necessary information is written to the respective files within that directory. The parent-child relationships of directories correspond to the parent-child relationships of cgroups. Figure 2 shows an example where " / sys / fs / cgroup" corresponds to the root cgroup, and " / sys / fs / cgroup / init.scope", " / sys / fs / cgroup / system.slice", and " / sys / fs / cgroup / user.slice" correspond to child cgroups with the root as their parent.

[0019] Note that the directory structure in Figure 2 is just one example (with 12 CPU cores, numbered 0 through 11).

[0020] In this embodiment, among the files belonging to each directory, cpuset.cpus, cgroup.subtree_control, and cgroup.proc are particularly used.

[0021] The cpuset.cpus file in a given directory specifies which CPU cores each of the cgroups under that directory will use. In other words, the cpuset.cpus file in a given directory specifies the amount (list) of CPU cores to be allocated to all processes belonging to the cgroup corresponding to that directory and all processes belonging to the cgroups corresponding to each directory under that directory. The OS controls CPU allocation based on cpuset.cpus, so the information stored in cpuset.cpus can be said to be information that shows the list of CPU cores actually allocated to each cgroup.

[0022] The cgroup.subtree_control file in a given directory manages the delegation of CPU allocation control privileges (hereinafter referred to as "CPU allocation privileges") to child cgroups corresponding to the child directories of that directory. If the string "cpuset" (controller name) is written in this file, the cgroup one level down can change the allocation of CPU cores to processes and threads belonging to that cgroup. Specifically, when cpuset is written to cgroup.subtree_control in a given directory (cgroup) (i.e., CPU allocation privileges are delegated), the Linux® OS generates cpuset.cpus in all child directories (all child cgroups) of that directory. In other words, cpuset.cpus files under directories corresponding to cgroups other than the root cgroup are not files that exist in each directory from the beginning, but are files that are generated for the directories of child cgroups to which CPU allocation privileges have been delegated from the parent cgroup. The OS decides whether or not to delegate CPU allocation privileges based on cgroup.subtree_control. Therefore, the information stored in cgroup.subtree_control can be said to represent the actual correspondence between the source and recipient of CPU allocation authority.

[0023] cgroup.proc is a file that exists in both the terminal and root cgroups and contains the PIDs of the processes and threads that actually belong to that cgroup.

[0024] Next, the terms used in this embodiment will be explained.

[0025] [CPU resources] Generally, server computers have multiple CPUs, and each CPU has one or more cores. This collection of CPU cores is considered a resource pool, and this resource pool is called a CPU resource.

[0026] [resource] CPU resources are sometimes simply referred to as "resources."

[0027] [Process thread] When a program runs on a multitasking OS, one unit (operational unit) is called a process or thread. A process consists of one or more threads. Therefore, the finest-grained operational unit is a thread.

[0028] [Resource Group] This refers to a group of processes or threads to which a certain CPU resource allocation rule (for example, allocating the first 5 to 10 CPU cores out of 20 cores) applies. In this embodiment, an example in which the above-mentioned cgroup is used as a resource group will be described.

[0029] [Assignment Rules] This refers to the rules governing the allocation of CPU resources applied to resource groups.

[0030] [Optimization] This refers to the process of changing the CPU core allocation, terminating the process or thread, or isolating the process or thread to a different resource group, in the event that a process or thread violates allocation rules or other rules.

[0031] [Delegation of Authority Rules] For allocation rules to be applied to a resource group, CPU allocation authority must be delegated to that resource group. Specifically, the parent resource group of that resource group must have cpuset described in its cgroup.subtree_control. This description establishes a correspondence between the resource group that delegates authority and the resource group to which authority is delegated (the correspondence between the parent group and its child group, where cpuset is described in cgroup.subtree_control). In this embodiment, the rules (prerequisites) regarding this correspondence are called authority delegation rules.

[0032] [CPU allocation privileges] This refers to the authority of a resource group to allocate CPU resources to processes and threads belonging to that resource group, within the scope of the CPU resources allocated to that resource group. As described above, in order for a resource group (cgroup) to obtain CPU allocation authority, it is necessary for the CPU allocation authority to be delegated from its parent resource group (cgroup).

[0033] Next, the functional requirements that the resource control device 10 in this embodiment must satisfy will be described.

[0034] [(1) There are unique rules for managing resources.] (1-1) For each resource group that distributes system resources such as CPU cores, rules can be created and applied, starting from that resource group, to determine what types of processes and threads should be included. (1-2) Rules can be created to specify, manage, and control how much CPU resources should be allocated to a given resource group. (1-3) Rules can be created for managing and controlling the delegation of CPU allocation authority.

[0035] [(2) It is possible to detect the behavior of processes that use resources.] (2-1) In accordance with the rules, it is possible to detect intrusions by processes and threads that do not belong to a certain resource group. (2-2) By following the rules, it is possible to detect changes in CPU resource allocation for a given resource group. (2-3) In accordance with the rules, changes in the delegation of CPU allocation privileges for a certain resource group can be detected.

[0036] [(3) After detecting a rule violation, the resource access that violated the rule can be corrected.] (3-1) Processes and threads that have entered a resource group in violation of the rules can be corrected in accordance with the rules. (3-2) Changes that violate the rules regarding the allocation of CPU resources to a certain resource group can be corrected in accordance with the rules. (3-3) Changes that violate the rules regarding the delegation of CPU allocation authority for a certain resource group can be corrected in accordance with the rules.

[0037] By meeting the above functional requirements, CPU resource allocation can be performed consistently and stably according to a unified rule.

[0038] Furthermore, the resource control device 10 can satisfy the following functional requirements.

[0039] [(4) The system will adapt to changes in resource access that increase or change as a result of system updates.] (4-1) Easy to add new features. (4-2) The addition of functionality must be applicable without stopping the OS while it is running.

[0040] Multitasking operating systems are updated daily, and APIs related to CPU resource allocation and associated process control are also updated accordingly. Consequently, unified resource management also needs to be updated. (4) is a functional requirement that enables the resolution of such problems.

[0041] To satisfy the above functional requirements, the resource control device 10 in this embodiment has the following functional configuration.

[0042] Figure 3 shows an example of the functional configuration of a resource control device 10 in an embodiment of the present invention. In Figure 3, the resource control device 10 includes a function start unit 11, a resource group rule file analysis unit 12, a resource group management unit 13, a CPU resource allocation management unit 14, an authority delegation management unit 15, a system call rule file analysis unit 16, a system call monitoring setting unit 17, a readiness confirmation unit 181, an event monitoring unit 182, and an optimization control unit 19, etc. Each of these units is realized by processing that one or more programs installed in the resource control device 10 cause the CPU 104 to execute.

[0043] The function start unit 11 initiates the processing to be executed by the resource control device 10.

[0044] The resource group rule file analysis unit 12 analyzes the resource group rule file r1.

[0045] The resource group rule file r1 is a file that contains the definition of each resource group and the rules applied to each resource group (such as CPU resource allocation rules). The following can be specified for each resource group in the resource group rule file r1: - Specification of rules regarding the processes and threads to which a process belongs (hereinafter referred to as "affiliation rules"), and specification of appropriate actions (stop, detection only, isolation) when a process or thread from a different affiliation intrudes. For example, it is possible to set a rule that only kernel threads belong to a certain resource group, and to isolate any process or thread that violates this rule by creating an isolation resource group (hereinafter referred to as the "isolation group"). • Specify the optimization process (revert to default settings or simply detect) when CPU resource allocation rules are changed. For example, if the CPU resource allocation is changed, it is possible to configure the system to revert the allocation back to its original value. - Specify the corrective action (revert to default settings or detect only) when the settings for delegating CPU allocation privileges between resource groups are changed. For example, if the delegation of authority to child resource groups in a certain resource group is disabled, it is possible to configure the system to promptly re-enable it, check cpuset.cpups, and perform appropriate adjustments.

[0046] The resource group rule file r1 is stored, for example, in auxiliary storage device 102.

[0047] The resource group management unit 13 generates each resource group based on the resource group rule file r1 and configures the event monitoring unit 182 to monitor changes in the configuration of processes and threads within each resource group (i.e., when a violation of the belonging rule occurs). The resource group management unit 13 also configures the optimization control unit 19 to execute optimization processing based on the settings in the resource group rule file r1 when a violation of the belonging rule is detected. In Figure 3, the resource management unit includes the resource group file status detection rule generation unit 131, the isolation area generation unit 132, and the resource group file status detection rule setting unit 133.

[0048] The CPU resource allocation management unit 14 configures the event monitoring unit 182 to monitor for changes in the CPU resource allocation settings for each resource group based on the resource group rule file r1 (i.e., when an allocation rule violation occurs). The CPU resource allocation management unit 14 also configures the optimization control unit 19 to execute optimization processing based on the settings in the resource group rule file r1 when an allocation rule violation is detected. In Figure 3, the CPU resource allocation management unit 14 includes the CPU resource allocation file status detection rule generation unit 141 and the CPU resource allocation file status detection rule setting unit 142.

[0049] The authority delegation management unit 15 configures the event monitoring unit 182 to monitor for changes in the setting value of the control authority to allocate CPU resources to each resource group based on the resource group rule file r1 (i.e., a violation of the authority delegation rule has occurred). The authority delegation management unit 15 also configures the optimization control unit 19 to execute optimization processing based on the settings in the resource group rule file r1 when a violation of the authority delegation rule is detected. In Figure 3, the authority delegation management unit 15 includes the authority delegation setting refile status detection rule generation unit 151 and the authority delegation setting file status detection rule setting unit 152.

[0050] The system call rule file analysis unit 16 analyzes the system call rule file r2.

[0051] The system call rule file r2 is a file in which system calls are dynamically added to be monitored in order to detect various changes caused by new system calls on the operating system (OS) that cannot be covered by monitoring based solely on settings by the resource group management unit 13, the CPU resource allocation management unit 14, or the authority delegation management unit 15 (changes in the configuration of processes and threads within each resource group, changes in the setting values ​​of CPU resources allocated to each resource group, and changes in the value of the control authority for allocating CPU resources). For example, to cover gaps in monitoring violations of membership rules, allocation rules, and authority delegation rules, system calls that cause changes to membership rules, allocation rules, or authority delegation rules can be added as monitoring targets. The system call rule file r2 is stored in, for example, an auxiliary storage device 102.

[0052] The system call monitoring setting unit 17 reads the system calls specified in the system call rule file r2 and configures the event monitoring unit 182 to detect the invocation of the system calls, in order to implement detection methods other than the detection of changes to existing operating system files, as envisioned by the resource group management unit 13, the CPU resource allocation management unit 14, or the authority delegation management unit 15. In Figure 3, the system call monitoring setting unit 17 includes the system call detection function generation unit 171 and the system call detection function setting unit 172.

[0053] The readiness confirmation unit 181 confirms the completion of processing by the resource group management unit 13, the CPU resource allocation management unit 14, the authority delegation management unit 15, and the system call monitoring setting unit 17.

[0054] The event monitoring unit 182 monitors events indicating changes to files specified in the settings of the resource group management unit 13, the CPU resource allocation management unit 14, or the authority delegation management unit 15. The event monitoring unit 182 also monitors system call invocation events specified in the settings of the system call monitoring setting unit 17. When the event monitoring unit 182 detects an event to be monitored, it notifies the optimization control unit 19 of the event.

[0055] When the optimization control unit 19 receives a notification from the event monitoring unit 182, it determines, based on the type of event related to the notification, whether the resource group management unit 13, the CPU resource allocation management unit 14, the authority delegation management unit 15, or the system call monitoring setting unit 17 is monitoring the event. If the optimization control unit 19 detects a violation of the belonging rule, allocation rule, or authority delegation rule based on the event, it executes a pre-configured optimization process. In Figure 3, the optimization control unit 19 includes an event occurrence waiting unit 191, a resource group rule violation determination unit 192, a system call rule violation determination unit 193, and an optimization process execution unit 194.

[0056] Furthermore, no modification of the existing OS (such as modification of the kernel space) is required for this embodiment.

[0057] The following describes the processing procedures performed by the resource control device 10. Figure 4 is a flowchart illustrating an example of the overall processing flow performed by the resource control device 10. The processing procedures in Figure 4 are initiated by the function start unit 11, for example, when the OS starts up.

[0058] In step S101, the resource control device 10 performs resource group rule file analysis and setting preparation processing. For example, the settings for resource group rule file r1 are analyzed, and preparation processing is performed to reflect the settings of resource group rule file r1 in the resource control device 10.

[0059] In step S102, the resource control device 10 performs system call rule file analysis and setting preparation processing. For example, the settings for the system call rule file r2 are analyzed, and preparation processing is performed to reflect the settings of the system call rule file r2 in the resource control device 10.

[0060] Note that the order of steps S101 and S102 may be reversed. Alternatively, steps S101 and S102 may be executed in parallel.

[0061] Next, the readiness confirmation unit 181 executes the readiness confirmation process (S103). In the readiness confirmation process, the information generated as a result of the preparation process in steps S102 and S101 (for example, information for detecting events to be monitored) is set to the event monitoring unit 182.

[0062] Next, the optimization control unit 19 executes event waiting processing (S104). In the event waiting processing, in response to the detection of a monitored event by the event monitoring unit 182, the optimization control unit 19 executes optimization processing according to the settings in the resource group rule file r1 or the system call rule file r2.

[0063] Next, we will explain the details of step S101. Figure 5 is a flowchart illustrating an example of the processing procedure for the resource group rule file analysis and configuration preparation process.

[0064] In step S111, the resource group rule file analysis unit 12 reads the settings of the resource group rule file r1 into the memory device 103.

[0065] Figure 6 shows an example of the configuration of resource group rule file r1. Figure 6 includes configuration information (resource group rules) for each resource group. One resource group rule includes items such as "Name", "Directory Path", "Assigned CPU Resources", "Eligible Processes / Threads", "Handling of Assignment Violations", "Handling of Assignment Violations", and "Handling of Authority Delegation Violations".

[0066] The "Name" is the name of the resource group. However, if each resource group can be identified by information other than its name, the "Name" is not necessary.

[0067] The "directory path" is the path name of the directory corresponding to the resource group. In this embodiment, the setting of the "directory path" column for each resource group corresponds to a delegation rule. Specifically, in this embodiment, it is assumed that the resource group of the parent directory in the "directory path" is the source of the CPU allocation authority, and the resource group of the child directory in the "directory path" is the recipient of that CPU allocation authority. Therefore, the setting of the "directory path" column is a rule (delegation rule) regarding the correspondence between the source and recipient of the CPU allocation authority.

[0068] "Assigned CPU resources" is configuration information related to the rules (i.e., assignment rules) that define the list of CPU cores to be assigned to a resource group or its descendants. Here, "resource group or its descendants" refers to the resource group itself and its descendant resource groups. Therefore, the "assigned CPU resources" of a given resource group can be specified from within the range of the "assigned CPU resources" of its parent resource group. Consequently, a resource group cannot be assigned CPU resources exceeding those of its parent resource group. If such a definition is made, the resource group rule file analysis unit 12 will consider the contents of the resource group rule file r1 to be invalid and will stop further processing. The contents of the "assigned CPU resources" of a given resource group are set in cpuset.cpus in the directory corresponding to that resource group. In this embodiment, cpuset.cpus is a file that is monitored for changes. Therefore, changes to the "assigned CPU resources" are effectively monitored.

[0069] "Eligible Processes / Threads" is configuration information regarding the rules (i.e., membership rules) that define the types of processes and threads that can belong to a resource group. The types of eligible processes and threads can be specified as "kthread," "user_proc," "user_proc_name," and "quarantine." It is also possible to include multiple types other than quarantine in a single resource group. In this case, the multiple types should be separated by a predetermined symbol (e.g., "|"). "kthread" indicates a kernel thread. "user_proc" indicates a user process. "user_proc_name" indicates a process associated with a specific program name. In the case of user_proc_name, the executable file name of the specific program is listed after user_proc_name, separated by commas. Regular expressions can be used to specify the executable file name. Note that "Eligible Processes / Threads" are not specified for isolation groups. "quarantine" refers to a process or thread isolated due to a violation of the rules set in the resource group rule file r1 or the system call rule file r2 (hereinafter simply referred to as "rule violation"). In other words, a resource group whose "Eligible Processes / Threads" value is "quarantine" is not a resource group to which CPU resources are allocated, but rather a resource group to which processes and threads that violate the rules are isolated.

[0070] The "Handling of Violations" setting specifies the action to be taken against a process or thread that violates the rules for which a process or thread can belong. The possible actions are "none," "quarantine," or "deny." "none" indicates no action (i.e., detection only). "quarantine" indicates that the violating process or thread will be quarantined in an isolation group. The name of the isolation group is specified after "|" following "quarantine." For example, "quarantine|quarantine1" means that the violating process will be quarantined in the isolation group named quarantine1. In this case, the process ID of the violating process or thread is written to the cgroup.procs file corresponding to the isolation group, and the process or thread is moved to the isolation group. At the same time, the CPU core allocation of the process to be quarantined is also changed. "deny" indicates that the violating process or thread is stopped. Note that violations of the "Eligible Processes and Threads" setting for a resource group (violations of the rules) are detected based on a change event in the cgroup.procs file in the directory corresponding to that resource group.

[0071] The "Handling of Allocation Violations" setting indicates the action to be taken when a violation occurs in the allocation rules, which are settings for "allocated CPU resources." It is possible to specify "revoke" or "none." "Revoke" means to cancel the setting, while "none" means to do nothing. Cancellation means to remove the violation (return to the state before the violation). Note that a violation of the "allocated CPU resources" setting (allocation rules) for a given resource group can be detected by detecting changes in the cpuset.cpus file corresponding to that resource group.

[0072] The "Handling of Delegation Violations" setting indicates the action to be taken when a violation of the delegation rules set in the "Directory Path" column occurs. It is possible to specify "revoke" or "none". The meanings of "revoke" and "none" are the same as those for "Handling of Assignment Violations". Note that a violation of a resource group's delegation rules can be detected by detecting changes in the cgroup.subtree_control corresponding to the parent resource group of that resource group.

[0073] Following step S111 in Figure 5, the resource group rule file analysis unit 12 analyzes the settings of the resource group rule file r1 and obtains the following information for each resource group specified in the resource group rule file r1: "Name", "Directory Path", "Assigned CPU Resources", "Eligible Processes / Threads", "Handling of Membership Violation", "Handling of Assignment Violation", and "Handling of Authority Delegation Violation" (S112).

[0074] Next, the resource group rule file analysis unit 12 opens one file descriptor using the inotify API (hereinafter referred to as the "file change detection file descriptor") to be used as a file descriptor to detect changes in the cgroup.procs, cpuset.cpus, and cgroup.subtree_control files of each resource group (S113).

[0075] Next, the resource group management unit 13 performs preparatory processing for detecting violations of the membership rules (S114).

[0076] Next, the CPU resource allocation management unit 14 performs preparatory processing for detecting violations of allocation rules (S115).

[0077] The authority delegation management unit 15 performs preparatory processing for detecting violations of authority delegation rules (S116).

[0078] Next, we will explain the details of step S114 in Figure 5. Figure 7 is a flowchart illustrating an example of the processing procedure for the preparation process for detecting violations of the membership rules. Here, based on the analysis results of the resource group rule file r1 by the resource group rule file analysis unit 12, rules related to the detection of membership violations are generated.

[0079] Specifically, in step S1141, the resource group file status detection rule generation unit 131 checks for the existence of a directory corresponding to each resource file, and if there is a directory that does not exist, it generates that directory. At this time, for resource groups where the value of "allocated CPU resources" is "quarantine", the isolation area generation unit 132 generates a directory for the isolation group as needed.

[0080] Next, the resource group file state detection rule generation unit 131 generates file state change detection rules for each resource group's cgroup.procs based on the specification of the "possible processes / threads" for each resource group (kthread, user_proc, user_proc_name, quarantine) and the specification of the "action to be taken when membership is violated" (S1142). The file state detection rule for a particular resource group is such that if a process / thread other than the "possible processes / threads" for that resource group intrudes into that resource group's cgroup.procs (directory path in resource group rule file r1 (Figure 6) / cgroup.procs), the action specified in the "action to be taken when membership is violated" for that resource group is executed.

[0081] Next, the resource group file status detection rule setting unit 133 uses the inotify API to configure the file descriptor for file change detection that was opened in step S113 of Figure 5, for each resource group, in order to detect changes in "directory path" / cgroup.procs (S1143).

[0082] Next, we will explain the details of step S115 in Figure 5. Figure 8 is a flowchart illustrating an example of the processing procedure for the preparation process for detecting allocation rule violations. Here, based on the analysis results of the resource group rule file r1 by the resource group rule file analysis unit 12, rules related to the detection of allocation rule violations are generated.

[0083] In step S1151, the CPU resource allocation file status detection rule generation unit 141 generates a file status change detection rule for each resource group's cpuset.cpus based on the "allocated CPU resources" specification and the "processing in case of allocation violation" specification in the resource group rule file r1 (Figure 6) (S1151). The file status detection rule for a particular resource group is such that if the cpuset.cpus of that resource group ("directory path" / cpuset.cpus" in the resource group rule file r1 (Figure 6)) is changed, the processing specified in the "processing in case of allocation violation" for that resource group is executed.

[0084] Next, the CPU resource allocation file status detection rule setting unit 142 uses the inotify API to configure the file descriptor for file change detection that was opened in step S113 of Figure 5, for each resource group, in order to detect changes in "directory path" / cpuset.cpus (S1152).

[0085] Next, we will explain the details of step S116 in Figure 5. Figure 9 is a flowchart illustrating an example of the processing procedure for the preparatory process for detecting violations of authority delegation rules.

[0086] In step S1161, the authority delegation setting refile status detection rule generation unit 151 generates file status change detection rules for the cgroup.subtree_control file in the parent directory of the "directory path" of each resource group ("directory path" parent directory / cgroup.subtree_control file) for each resource group except the root resource group ("root cgroup" in Figure 6), based on the "directory path" specification and "processing in case of authority delegation violation" specification in the resource group rule file r1 (Figure 6) (S1161). The file status detection rule for a certain resource group is a rule that executes the processing specified in the "processing in case of authority delegation violation" of that resource group when the cgroup.subtree_control file in the parent directory of the "directory path" of that resource group is changed. Note that there may be multiple resource groups that share the same parent directory of the "directory path" (i.e., share the same cgroup.subtree_control file to be monitored). In this case, one file status detection rule corresponding to the revoke process, which has a significant impact on processing among these multiple resource groups, is generated for all of these resource groups.

[0087] Next, the authority delegation setting file status detection rule setting unit 152 uses the inotify API to configure the file descriptor for file change detection that was opened in step S113 of Figure 5, for each cgroup.subtree_control file to be monitored, in order to detect changes in that file (S1162).

[0088] Next, we will explain the details of step S102 in Figure 4. Figure 10 is a flowchart illustrating an example of the system call rule file analysis and configuration preparation process.

[0089] In step S121, the system call rule file analysis unit 16 reads the settings of the system call rule file r2 into the memory device 103.

[0090] Figure 11 shows an example of the configuration of the system call rule file r2. The system call rule file r2 contains one system call rule line for each system call to be detected. Each system call rule includes items such as "Specified Type," "Target System Call Name," "Policy Name," and "Processing Method."

[0091] The "Specified Type" field specifies how the system calls to be detected (captured) will be detected (captured). In this embodiment, the ebpf function of Linux (registered trademark) is used, so an example is shown where "bpf_program," which indicates this function, is specified.

[0092] "Target system call name" is the name of the system call to be detected.

[0093] The "policy name" is the name of the pattern for detecting system calls (in other words, the pattern for applying the "processing method"). In Figure 11, "all" indicates that all calls will be detected. Other options include setting a frequency to detect only once every 10 calls.

[0094] The "processing method" specifies the method of processing to be executed when the system call related to the "target system call name" is invoked, and can be set to "cgroup_check" or "none". "none" indicates that only detection will be performed (i.e., nothing will be done). "cgroup_check" indicates that the process associated with the detected system call will be controlled based on the "possible processes" and "processing in case of membership violation" of the resource group rule file r1 (Figure 6). For example, clone3 related to the "target system call name" in Figure 11 is a new system call that can create a process and specify the resource group to which that process belongs, and "cgroup_check" is specified for the "processing method" of this system call. In this case, it is determined whether there is a violation of the "possible processes and threads" set in the resource group rule file r1 (Figure 6). If the created process is a user process but is created as a process belonging to the resource group corresponding to a Kernel thread, then in Figure 6, it will be considered a violation of the "possible processes and threads" of the root resource group (root cgroup). Therefore, based on the "action to be taken when belonging to a resource group is violated" specification (quarantine|quarantine1) for that resource group, the process is quarantined to quarantine1, one of the isolation resource groups. However, if the process is created by clone3, inotify cannot detect the change in cgroup.procs. As a result, the belonging rule violation for that process cannot be detected. Therefore, clone3 is separately designated as a target for detection (monitoring) in the system call rule file r2. In other words, the system call rule file r2 is introduced to detect violations that cannot be fully covered by the resource group rule file r1 (Figure 6).

[0095] Following step S121 in Figure 10, the system call rule file analysis unit 16 analyzes each line of the system call rule file r2 to determine which system calls are to be monitored and what processing needs to be done when those system calls are invoked (S122).

[0096] Next, the system call detection function generation unit 171 generates a function to detect the invocation of a system call and notify the event monitoring unit 182 based on the "designation type" of the line corresponding to the system call specified as a monitoring target in the system call rule file r2 (Figure 11) (S123).

[0097] For example, according to Figure 11, the "specified type" for clone3 is "bpf_program". In this case, the system call detection function generation unit 171 generates an "ebpf program" as the function to detect calls to clone3 using ebpf / kprobes. Note that an ebpf program is a small program of about one line.

[0098] Next, the system call detection function setting unit 172 sets the function generated in step S123 (for example, the ebpf program) to the OS (or to the BPF management unit in the case of the ebpf program) (S124) so ​​that it can receive an event indicating that the monitored system call has been invoked.

[0099] Next, the system call detection function setting unit 172 generates a file descriptor to be used as the recipient of the event (hereinafter referred to as the "system call detection file descriptor") (S125).

[0100] Next, we will explain the details of step S103 in Figure 4. Figure 12 is a flowchart illustrating an example of the processing procedure for the readiness confirmation process.

[0101] In step S131, the readiness confirmation unit 181 receives the system call detection file descriptor generated in step S125 in Figure 7 from the system call monitoring setting unit 17, and receives the file change detection file descriptor, which was opened in step S113 in Figure 5 and configured by the resource group file state detection rule setting unit 133, the CPU resource allocation file state detection rule setting unit 142, and the authority delegation setting file state detection rule setting unit 152, from the resource group rule file analysis unit 12. The system call detection file descriptor is a file descriptor for detecting the invocation of the system call to be monitored. The latter file descriptor is a file descriptor for detecting changes in the state of files such as cgroup.procs, cpuset.cpus, or cgroup.subtree_control.

[0102] Next, the readiness confirmation unit 181 sets these two file descriptors for the event monitoring unit 182 (S132). As a result, the event monitoring unit 182 can use these file descriptors to detect the invocation of system calls that are being monitored and changes to various files that are being monitored as events. The event monitoring unit 182 notifies the optimization control unit 19 of the detected events.

[0103] Next, we will explain the details of step S104 in Figure 4. Figure 13 is a flowchart illustrating an example of the processing procedure for event waiting.

[0104] The event occurrence waiting unit 191 waits for event notification from the event monitoring unit 182 (S141). When the event occurrence waiting unit 191 receives an event detected by the event monitoring unit 182 from the event monitoring unit 182 (Yes in S141), the event occurrence waiting unit 191 determines, based on the notification from the event monitoring unit 182, which of the two file descriptors detected the event (S142).

[0105] If the event is detected in a file descriptor for file change detection (referred to as "for file change detection" in S142), the optimization control unit 19 executes processing corresponding to the file state change (S143). If the event is detected in a file descriptor for system call invocation detection (referred to as "for system call detection" in S142), the optimization control unit 19 executes processing corresponding to the system call invocation (S144).

[0106] Next, we will explain the details of step S143. Figure 14 is a flowchart illustrating an example of the processing procedure for handling changes in the file state.

[0107] In step S1431, the resource group rule violation determination unit 192 splits the full path name of the modified (post-modification) file (hereinafter referred to as the "target file") included in the notification from the event monitoring unit 182 into a directory name and a file name.

[0108] Next, the resource group rule violation determination unit 192 determines whether there is a file status change detection rule related to the directory name of the target file (i.e., the resource group related to that directory name (hereinafter referred to as the "target resource group")) among the file status change detection rules generated by the resource group file status detection rule generation unit 131, the CPU resource allocation file status detection rule generation unit 141, or the authority delegation setting refile status detection rule generation unit 151 (i.e., the rule corresponding to any line in the resource group rule file r1 (Figure 6)) (1432). A file status change detection rule related to that directory name refers to a file status change detection rule in which the "directory path" of the target file matches that directory name.

[0109] If there is a corresponding file state change detection rule (hereinafter referred to as the "target file state change detection rule") (Yes in S1432), the resource group rule violation determination unit 192 branches the processing based on the file name of the target file (S1433).

[0110] If the file name of the target file is "cgroup.procs" (as in "cgroup.procs" in S1433), the resource group rule violation determination unit 192 starts processing when cgroup.procs is modified (S1434).

[0111] If the file name of the target file is "cpuset.cpus" (as indicated in S1433), the resource group rule violation determination unit 192 starts processing when cpuset.cpus is changed (S1435).

[0112] If the file name of the target file is "cgroup.subtree_control" (as indicated in S1433), the resource group rule violation determination unit 192 starts processing when cgroup.subtree_control is changed (S1436).

[0113] Next, we will explain the details of step S1434. Figure 15 is a flowchart illustrating an example of the processing procedure when cgroup.procs is modified.

[0114] In step S201, the resource group rule violation determination unit 192 reads one of the process IDs listed on each line in the target file, cgroup.procs. Hereinafter, the read process ID will be referred to as the "target ID".

[0115] Next, the resource group rule violation determination unit 192 determines whether the "possible process / thread" specification of the target file state change detection rule is "kthread" or "user_proc" or "user_proc_name" (S202).

[0116] If the "possible processes / threads" specified in the target file state change detection rule is "kthread" or "user_proc" (as in "kthread" or "user_proc" in S202), the resource group rule violation determination unit 192 obtains the type of process associated with the target ID (hereinafter referred to as the "target process") based on the target ID (S203). For example, the type of the target process can be obtained by reading the flags (process kernel flag word) from the / proc / [target ID] / stat information and extracting the process type from the flags information.

[0117] Next, the resource group rule violation determination unit 192 checks whether the type of the acquired process matches the "possible process / thread" of the target file state change detection rule (S204). If it does not match (i.e., the target process does not belong to the type indicated by "possible process / thread"), the resource group rule violation determination unit 192 determines that the target process has violated the membership rule for the target resource group.

[0118] On the other hand, if the "possible processes / threads" specification for the target file state change detection rule is "user_proc_name" (in S202, "user_proc_name"), the resource group rule violation determination unit 192 obtains the executable file name of the target process (S205). For example, the executable file name of the target process can be obtained by reading the / proc / [target ID] / status information.

[0119] Next, the resource group rule violation determination unit 192 checks whether the acquired executable file name matches the executable file name listed after "user_proc_name" in the "Eligible Processes / Threads" section of the target file state change detection rule (S206). If they do not match, the resource group rule violation determination unit 192 determines that the target process has violated the rules for belonging to the target resource group.

[0120] If it is determined in step S204 or step S206 that there is no violation of the target process's affiliation with the target resource group (No in S207), the process proceeds to step S209. If it is determined that there is a violation of the target process's affiliation with the target resource group (Yes in S207), step S208 is executed before proceeding to step S209.

[0121] In step S208, the optimization processing execution unit 194 executes the processing (optimization processing) specified in the "Processing when a group is violated" of the target file state change detection rule (Figure 6). If "quarantine" is specified in "Processing when a group is violated", the optimization processing execution unit 194 moves the target process to the isolation group specified after "quarantine". In this case, the optimization processing execution unit 194 writes the target ID to cgroup.procs corresponding to the isolation group and also changes the CPU core allocation.

[0122] In step S209, the resource group rule violation determination unit 192 determines whether it has read the process IDs for all lines of the target file, cgroup.procs. If there are any unprocessed process IDs (No in S209), the process returns to step S201. In this case, one of the unprocessed process IDs is read in step S201. If the process IDs for all lines have been read (Yes in S209), the process in Figure 15 is terminated.

[0123] Next, we will explain the details of step S1435 in Figure 14. Figure 16 is a flowchart illustrating an example of the processing procedure when cpuset.cpus is modified.

[0124] In step S211, the resource group rule violation determination unit 192 obtains the contents of the target file, cpuset.cpus, and obtains a list of CPU cores assigned to the target resource group and its sub-groups (S211).

[0125] Next, the resource group rule violation determination unit 192 determines whether the acquired CPU core list violates the "allocated CPU resources" of the target file state change detection rule (Figure 6) (i.e., whether there is an allocation rule violation) (S212). The state in which the acquired CPU core list violates the "allocated CPU resources" of the target file state change detection rule (Figure 6) means that the acquired CPU core list is different from the "allocated CPU resources" in question.

[0126] If there are no allocation rule violations (No in S212), the subsequent processing is not executed. If there are allocation rule violations (Yes in S212), and the "Processing when allocation violation occurs" setting in the target file state change detection rule (Figure 6) is set to "revoke" (Yes in S213), the optimization processing execution unit 194 writes the contents of the target file, cgroup.procs, back to its state before the change (S214). The state before the change is saved in the memory device 103.

[0127] Next, we will explain the details of step S1436 in Figure 14. Figure 17 is a flowchart illustrating an example of the processing procedure when cgroup.subtree_control is changed.

[0128] In step S221, the resource group rule violation determination unit 192 retrieves the contents (controller names) described in the target file cgroup.subtree_control. cgroup.subtree_control contains controller names that indicate the permissions for allocating not only CPUs but also various other resources.

[0129] Next, the resource group rule violation determination unit 192 determines whether or not "cpuset" is present among the acquired controller names (S222). "cpuset" is a controller name that indicates CPU allocation authority. If "cpuset" is included in cgroup.subtree_control, the delegation of CPU allocation authority to the child resource group is permitted.

[0130] If "cpuset" is among the retrieved controller names (Yes in S222), no violation of the authority delegation rule has occurred, and the process in Figure 17 terminates.

[0131] On the other hand, if "cpuset" is not among the acquired controller names (i.e., "cpuset" has been deleted from the target file and there is a violation of the authority delegation rule) (No in S222), and if the "Processing when authority delegation is violated" specification in the target file state change detection rule (Figure 6) is "revoke" (Yes in S223), the optimization processing execution unit 194 writes "cpuset" back to the target file, cgroup.subtree_control (S224). In addition, the optimization processing execution unit 194 also checks the cpuset.cpus file for the "child resource group," which is a child directory of this parent directory, based on the assignment rule file, and restores it to an appropriate state.

[0132] Next, we will explain the details of step S144 in Figure 13. Figure 18 is a flowchart illustrating an example of the processing procedure for handling a system call.

[0133] In step S1441, the system call rule violation determination unit 193 obtains information from the process's struct clone_args indicating the resource group to which the process generated by the detected system call (hereinafter referred to as the "target system call") belongs. For example, if a call to clone3, which is set in the system call rule file r2 in Figure 11, is detected, information indicating the resource group to which the process generated by clone3 belongs is obtained.

[0134] Next, the system call rule violation determination unit 193 determines whether the "processing method" set for the "target system call name" of the target system call in the system call rule file r2 (Figure 11) is "cgroup_check" (S1442).

[0135] If the "processing method" is "cgroup_check" (Yes in S1442), the system call rule violation determination unit 193 determines whether the "possible processes / threads" specification of the resource group rule corresponding to the target resource group (hereinafter referred to as the "target rule") in the resource group rule file r1 (Figure 6) is "kthread" or "user_proc" or "user_proc_name" (S1443).

[0136] If the "possible processes / threads" specified in the target rule is "kthread" or "user_proc" (as indicated in S1443), the system call rule violation determination unit 193 obtains the type of the process (hereinafter referred to as the "target process") based on the process ID of the generated process (S1444). For example, the type of the target process can be obtained by reading the flags (process kernel flag word) from the / proc / [target ID] / stat information and extracting the process type from the flags information.

[0137] Next, the system call rule violation determination unit 193 checks whether the type of process acquired matches the "eligible processes / threads" of the target rule (S1445). If it does not match, the system call rule violation determination unit 193 detects a violation of the target process's affiliation with the target resource group.

[0138] On the other hand, if the "possible processes / threads" specified in the target rule is "user_proc_name" (in S1443, "user_proc_name"), the system call rule violation determination unit 193 obtains the executable file name of the target process (S1446). For example, the executable file name of the target process can be obtained by reading the / proc / [target ID] / status information.

[0139] Next, the system call rule violation determination unit 193 checks whether the acquired executable file name matches the executable file name listed after "user_proc_name" in the "Eligible Processes / Threads" section of the target rule (S1447). If they do not match, the system call rule violation determination unit 193 detects a violation of the membership rule for the target resource group for the target process.

[0140] If a violation of the membership rule for the target resource group is detected for the target process in step S1445 or step S1447 (Yes in S1448), the optimization processing execution unit 194 executes the processing (optimization processing) specified in "Processing when membership violation occurs" of the target rule (Figure 6). If "quarantine" is specified in "Processing when membership violation occurs", the optimization processing execution unit 194 moves the target process to the isolation group specified after "quarantine". In this case, the target ID is written to cgroup.procs corresponding to the isolation group, and the CPU core allocation is also changed.

[0141] In contrast to the conventional libcgroup technology, which assigns resources to appropriate resource groups based on allocation rules created using UID / GID, the following issues exist in terms of CPU resource allocation to resource groups.

[0142] (Problem 1) If a process or thread that should not belong to a resource group under a certain allocation rule infiltrates that resource group and uses CPU resources, the allocation rule is violated. In this case, there is no function to correct the situation (conventional technology only moves the process to a resource group configured based on UID / GID / process name, and processes without a specified UID / GID / process name are not controlled).

[0143] (Problem 2) There is no function to monitor the allocation rules for CPU resources, and if those rules are overwritten (for example, if the allocation is changed from 0-3 cores to 0-1 cores), there is no function to revert to the original rules.

[0144] (Problem 3) There is no monitoring function for the authority delegation rules that serve as the basis for applying the allocation rules to the relevant resource group. There is no function to revert to the original state if the authority delegation rules are rewritten, and in the worst case, the allocation rules cannot be executed.

[0145] (Issue 4) With system updates, there is no function to add APIs related to CPU resource allocation that may be added, while operating the functionality dynamically in a plug-in format to control those APIs.

[0146] (Problem 5) It is not possible to set fine-grained assignment rules at the thread level, which is the granularity of the OS, for the processes and threads to be controlled.

[0147] Therefore, libcgroup cannot achieve the same effects as in this embodiment and cannot satisfy the functional requirements of the resource control device 10 in this embodiment.

[0148] As described above, this embodiment makes it possible to realize a mechanism that consistently and stably allocates CPU resources according to a unified rule. In this embodiment, by setting the types of processes and threads that should belong to a certain resource group, it is possible to manage the CPU resources allocated to a certain resource group and prevent omissions in CPU resource management.

[0149] Furthermore, it is possible to perform optimization processing (such as a write-back function) in response to changes (rewriting) of CPU resources allocated to resource groups.

[0150] Furthermore, the system also monitors the delegation of CPU allocation authority settings, which delegate the authority to modify (rewrite) CPU resources. If a violation of the rules is detected, corrective processing is performed, thereby ensuring thorough CPU resource management in conjunction with the allocated amount of CPU resources.

[0151] Furthermore, as a preventative measure against potential future instances of configuration value rewriting, a detection function related to the creation of new processes and threads via system calls, which cannot be handled by existing file-based detection interfaces, can be added by utilizing the system call rule file r2.

[0152] In this embodiment, cpuset.cpus is an example of the first file. cgroup.proc is an example of the second file. cgroup.subtree_control is an example of the third file. The event monitoring unit 182 is an example of the first detection unit and the second detection unit. The resource group rule violation determination unit 192 is an example of the determination unit. The optimization processing execution unit 194 is an example of the first processing execution unit and the second processing execution unit. The assignment rule is an example of the first rule. The membership rule is an example of the second rule. The authority delegation rule is an example of the third rule. The system call rule is an example of the fourth rule.

[0153] Although embodiments of the present invention have been described in detail above, the present invention is not limited to these specific embodiments, and various modifications and changes are possible within the scope of the gist of the present invention as described in the claims. [Explanation of symbols]

[0154] 10 Resource Control Unit 11 Function start part 12 Resource Group Rule File Analysis Unit 13 Resource Group Management Department 14. CPU Resource Allocation Management Unit 15. Delegation of Authority Management Department 16 System Call Rule File Analysis Unit 17 System Call Monitoring Settings Section 19 Optimization Control Unit 100 drive unit 101 Recording media 102 Auxiliary storage device 103 Memory device 104 CPU 105 Interface device 131 Resource Group File Status Detection Rule Generation Unit 132 Isolated area generator 133 Resource Group File Status Detection Rule Setting Section 141 CPU Resource Allocation File State Detection Rule Generation Unit 142 CPU Resource Allocation File Status Detection Rule Setting Section 151 Authority Delegation Setting Refile Status Detection Rule Generation Unit 152 Authority Delegation Setting File Status Detection Rule Setting Section 171 System Call Detection Function Generation Unit 172 System Call Detection Function Setting Section 181 Preparation completion confirmation section 182 Event Monitoring Department 191 Event Occurrence Waiting Section 192 Resource Group Rule Violation Determination Unit 193 System Call Rule Violation Determination Unit 194 Optimization Processing Execution Unit B Bus r1 Resource Group Rule File r2 System Call Rule File

Claims

1. A first detection unit detects changes to any of the following: a first file which stores information indicating a list of CPU cores actually allocated to each of a plurality of groups set with respect to the program's operating units; a second file which stores information indicating the group to which each of the operating units actually belongs; and a third file which stores information indicating the actual correspondence between the group that delegates the CPU core allocation authority for the operating units by the group and the group to which the delegation is transferred. When the first detection unit detects a change in any file, the determination unit determines whether there is a violation of the first rule that defines the list of CPU cores to be assigned to each of the aforementioned groups, the second rule that defines the types of operating units that can belong to each of the aforementioned groups, or the third rule that defines the correspondence between the group that delegates the authority to assign CPU cores to the aforementioned operating units and the group to which the authority is delegated, based on the contents of the file after the change. If the determination unit determines that there is a violation, the first processing execution unit executes the processing set for violations of the first rule, the processing set for violations of the second rule, and the processing set for violations of the third rule, which corresponds to the violation. It has, The type of the aforementioned operating unit is distinguished by whether or not it is a kernel thread, whether or not it is a user process, whether or not it is the aforementioned operating unit relating to a specific program name, or whether or not it is the aforementioned operating unit that violates any of the first, second, or third rules. A resource control device characterized by the following features.

2. The determination unit, when it detects a change in the first file, determines that there is a violation of the first rule if the operating unit, which is indicated in the information stored in the modified first file to belong to one of the groups, does not belong to the type of program operating unit that can belong to the group set in the first rule. The resource control device according to claim 1, characterized in that it is a resource control device.

3. When the determination unit detects a change in the second file, it determines that there is a violation of the second rule if the list of CPU cores that are assigned to any group, as indicated by the information stored in the modified second file, differs from the list of CPU cores set for that group in the second rule. The resource control device according to claim 1, characterized in that it is a resource control device.

4. When the determination unit detects a change in the third file, it determines that there is a violation of the third rule if the correspondence between the delegator and the delegator indicated by the information stored in the modified third file differs from any of the correspondences set in the third rule. The resource control device according to claim 1, characterized in that it is a resource control device.

5. A second detection unit detects a system call based on a fourth rule which defines the system calls to be detected and the processing to be executed when such a system call is detected. When the second detection unit detects the invocation of the system call, a second processing execution unit executes the processing set out in the fourth rule, A resource control device according to any one of claims 1 to 4, characterized by having the following:

6. A first detection procedure for detecting changes to any of the following: a first file which stores information indicating a list of CPU cores actually allocated to each of a plurality of groups set with respect to the program's operating units; a second file which stores information indicating the group to which each of the operating units actually belongs; and a third file which stores information indicating the actual correspondence between the group that delegates the CPU core allocation authority for the operating units by the group and the group to which the delegation is transferred. If the first detection procedure detects a change in any file, a determination procedure is provided to determine whether the contents of the changed file violate a first rule that defines a list of CPU cores to be assigned to each of the aforementioned groups, a second rule that defines the types of operating units that can belong to each of the aforementioned groups, or a third rule that defines the correspondence between the group that delegates the authority to assign CPU cores to the operating unit and the group to which the authority is delegated. If the determination procedure determines that there is a violation, the first processing execution procedure executes the processing set for violations of the first rule, the processing set for violations of the second rule, and the processing set for violations of the third rule, which corresponds to the violation. The computer executes this, The type of the aforementioned operating unit is distinguished by whether or not it is a kernel thread, whether or not it is a user process, whether or not it is the aforementioned operating unit relating to a specific program name, or whether or not it is the aforementioned operating unit that violates any of the first, second, or third rules. A resource control method characterized by the following:

7. A first detection procedure for detecting changes to any of the following: a first file which stores information indicating a list of CPU cores actually allocated to each of a plurality of groups set with respect to the program's operating units; a second file which stores information indicating the group to which each of the operating units actually belongs; and a third file which stores information indicating the actual correspondence between the group that delegates the CPU core allocation authority for the operating units by the group and the group to which the delegation is transferred. If the first detection procedure detects a change in any file, a determination procedure is provided to determine whether the contents of the changed file violate a first rule that defines a list of CPU cores to be assigned to each of the aforementioned groups, a second rule that defines the types of operating units that can belong to each of the aforementioned groups, or a third rule that defines the correspondence between the group that delegates the authority to assign CPU cores to the operating unit and the group to which the authority is delegated. If the determination procedure determines that there is a violation, the first processing execution procedure executes the processing set for violations of the first rule, the processing set for violations of the second rule, and the processing set for violations of the third rule, which corresponds to the violation. Have the computer run it, The type of the aforementioned operating unit is distinguished by whether or not it is a kernel thread, whether or not it is a user process, whether or not it is the aforementioned operating unit relating to a specific program name, or whether or not it is the aforementioned operating unit that violates any of the first, second, or third rules. A program characterized by the following features.

Images