JP2013218744A - Resource-based scheduler - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide resource-based scheduling of a computer job.SOLUTION: A computer job is scheduled based on utilization of a resource and a utilization criterion that the computer job has pertaining to the resource. A process 200 for resource-based scheduling comprises: a step (202) of receiving utilization criteria of one or more jobs; a step (204) of determining utilization criteria of the one or more jobs; a step (206) of adding computer jobs to resource-based scheduling worklists; a step (208) of selecting a particular computer resource to be utilized; a step (210) of determining utilization of the selected computer resource; and a step (214) of storing resource utilization information regarding an executed computer job.

Description

The present invention relates to scheduling computer jobs. In particular, embodiments of the invention relate to scheduling computer jobs based on resource usage criteria for a particular job and the utilization of computer resources used by the job.

BACKGROUND Today's computer operating systems (O / S) utilize a multitasking scheduler to give the appearance of two or more computer jobs (eg, processes) that operate simultaneously. There are many different scheduling algorithms, but the general idea is that a small time slice, known as quantum, is given to one thread of a process and then given to another thread or another process of that process, etc. It is. The quantum length is very small, typically in the range of 20-120 milliseconds. Due to human time perception, jobs appear to be working simultaneously.

  Central processing units (CPUs) tend to be the fastest component of most computer systems, whereas other computers such as disk I / O, network I / O, and even memory Resources tend to be much slower. For example, disk I / O would be about one million times slower than the CPU when measured in terms of data transfer from the disk and data transfer within the CPU. As a result, the CPU often waits for these slower resources. For example, a 3 GHz CPU is often idle while waiting for the disk drive to retrieve data with an average access time measured in milliseconds.

  Since several different jobs often compete for the same resource, the jobs often collide with each other, resulting in one or more jobs being slow. From the user's perspective, job collisions appear as unresponsive applications, jerky cursor movements, and slowly displayed graphics.

  Throttling is a technique for minimizing these negative effects. Throttling prevents an application or job from using more than the amount of allocated resources. Types of throttling include disk I / O throttling, CPU throttling, and network throttling. For example, CPU throttling may involve establishing a target CPU utilization limit for an application and forcing the application to stop operating when the application exceeds the target limit. Throttling is sometimes applied to computer resources for maintenance applications or less important computer jobs. Although throttling has advantages, the resource usage of computer jobs is not completely transparent to other jobs and applications.

  The above problem is even more troublesome. This is because computer resources are generally wasted over 24 hours. For example, most desktops use less than 5% of the computer's available resources, and high traffic servers often use approximately 20%. Even computers that use 80-90% of the resources still have 10-20% available resources.

  To recover and utilize those resources that would otherwise be lost, what is needed enables execution of one or more jobs within the computer system without significantly affecting other jobs or applications Technology. This technique should not consume user time when scheduling a job, nor should it negatively affect user interaction with the computer system when the job is running.

  The strategies described in this section are those that can be pursued, but not necessarily those that were previously conceived or pursued. Therefore, unless otherwise specified, it should not be assumed that any of the strategies described in this section are considered prior art simply because they are included in this section.

  The present invention is illustrated by way of example and not limitation in the accompanying drawings in which like reference numerals refer to like elements.

FIG. 4 is a resource-based scheduler having a resource-based scheduling worklist according to an embodiment of the present invention. FIG. 4 is a diagram of a resource-based scheduler according to another embodiment of the invention. FIG. 6 is a resource-based scheduling flowchart according to an embodiment of the present invention. FIG. And FIG. 6 is a block diagram illustrating a computer system in which embodiments of the invention may be implemented.

In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent that the invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

Overview The vast majority of computers do not always use all of their resource capacity. This is typically true for computers that appear to be in good use 24 hours a day, 7 days a week, and computers that are set up for only a short time each day. Thus, computer time and resources are wasted. For example, a computer system that is heavily used over a 24-hour period and that can have a brief spike when active may use on average about 5-20% of resources.

  Computer jobs are scheduled based on resource usage and the usage criteria that the computer job has regarding resources in accordance with embodiments of the present invention. For example, a computer job may have a usage criterion that disk I / O resources have 60% available capacity for scheduling computer jobs. In this embodiment, a computer job is not scheduled if the available capacity of the disk I / O resource is less than 60%.

  In one embodiment, a resource-based scheduler (RBS) places each computer job on at least one of several different resource-based scheduling worklists. Scheduling worklists based on these resources include, but are not limited to, disk I / O scheduling worklist, CPU scheduling worklist, and network I / O scheduling worklist. Thus, a particular scheduling worklist comprises computer jobs waiting to use a particular resource. In this embodiment, each computer job has usage criteria for a particular resource. The RBS then selects one of the resources to schedule the computer job. In one embodiment, the selection is based on resource priority. For example, disk I / O resources may have a higher priority than CPU resources. In one embodiment, resources referred to as slower resources are given higher priority than resources referred to as faster resources.

  After selecting which resource to schedule, the RBS selects one of the computer jobs for execution from the work list corresponding to the selected resource. In one embodiment, the RBS selects a computer job based on criteria that match the available capacity of the resource to the computer job usage criteria. However, the RBS may also use other factors such as the priority of computer jobs, the required execution order of computer jobs, and the order in which computer jobs are placed on the work list.

  Note that in one embodiment, the RBS uses the resources used by a job (entirely or partially) even if other resources that the job does not require are used (in whole or in part) by other jobs. Scheduling each computer job when available (in part or in part) enables efficient use of multiple computer resources and reduces performance violations of other jobs.

Resource Based Scheduler FIG. 1A is a diagram of a resource based scheduler (RBS) 100 having a resource based scheduling worklist 120 in accordance with an embodiment of the present invention. The RBS 100 schedules computer jobs proactively based on the available capacity of different computer resources. By way of example, different resources may include, but are not limited to, CPU, disk I / O, network I / O, video, memory, keyboard, network resources, and the like. The term “computer job” or “job”, as used herein, includes any part of a computer process, thread, microjob (described later herein), or executable computer code. However, it is not limited to these. The RBS 100 may allow each computer job to receive resource requirements without conflicting with resource requirements of any other job. In one embodiment, the RBS 100 can determine when a particular resource is only partially used, with minimal infringement of any of the other jobs that are already using the resource, and unused Can be assigned to the selected job.

  In one embodiment, RBS 100 schedules computer jobs for a variety of different resources. The different resources may be on the same computer system as the RBS 100, or may not be on the same computer system as the RBS 100. For example, in one embodiment, RBS 100 schedules computer jobs to utilize resources accessed over the network. As a specific example, the resource may be accessed via the Internet.

  Thus, in one embodiment, the RBS 100 receives computer jobs seeking access to various resources, which computer jobs should be scheduled to use which resources, and when computer jobs should be scheduled Make a scheduling decision about whether

Computer Resource Usage The RBS 100 inputs resource usage information 105 representing the usage of various computer resources. Usage may be related to an interval or a specified point in time. The usage may be an average usage over a specified interval. For example, resource utilization can be specified as an average utilization over a specified time interval. As a specific example, 30% utilized CPU resources may be associated with average utilization over recent time intervals. In one embodiment, the spacing is measured in quantum units.

  In one embodiment, usage is based on numerical values. For example, usage may be based on the number of operations waiting to be executed at a specified time. For example, if the resource has an “x” operation waiting to be executed, the usage may be “x”. As another example of resource utilization based on numerical values, utilization is based on the number of utilization requests for a particular resource. For example, in one embodiment, utilization is based on the total number of utilization requests for a particular resource that each process has. Numeric based usage may be related to a point in time or interval. For example, in one embodiment, numerical resource utilization is based on the average number of operations awaiting execution over a particular time interval. In another embodiment, the numerical resource utilization is based on the number of operations awaiting execution at a particular point in time.

  In one embodiment, RBS 100 estimates future resource usage based on resource usage 105. For example, an estimate of future resource usage is made based on the number of usage requests for a particular resource (and possibly other factors). As another example, an estimate of future resource usage is made based on the utilization rate of a particular resource (and possibly other factors).

Computer Job Usage Criteria RBS 100 also inputs usage criteria 118 for jobs to be scheduled. Usage criteria 118 are associated with resources. For example, a resource threshold may be used, and if the resource usage by other jobs falls below the threshold, the RBS 100 simply schedules a computer job. One example of using a resource threshold is that the RBS 100 simply schedules a particular computer job to use the disk I / O when the disk I / O has an available capacity of less than 60%. In one embodiment, RBS 100 has an Application Program Interface (API) for the application that owns the computer job to provide usage criteria 118. An exemplary API is provided herein.

  In one embodiment, usage criteria 118 is based on time. Basing the usage criterion 118 on a percentage is an example of a time-based criterion. In one embodiment, usage criteria 118 is based on numerical values. An example of a usage criterion 118 based on a numerical value is the number of operations awaiting execution on a particular resource. Another example of a numeric based usage metric 118 is a number of requests received to use a resource. For example, the usage criteria 118 for a particular process is based on the number of usage requests for a particular resource.

  In one embodiment, the RBS 100 stores history usage information 116. History usage information 116 represents previous resource usage by one or more jobs. For example, the fact that a computer job used 30% of the network I / O resources is stored for future reference. In one embodiment, the RBS 100 uses the historical usage information 116 to determine usage criteria for computer jobs to be scheduled. For example, based on one or more previous times that a computer job utilized a particular resource, RBS 100 determines that the computer job has an “x”% utilization criterion for the particular resource. RBS 100 then uses this usage criterion when scheduling computer jobs.

  The RBS 100 also inputs executable code 108 of the job to be scheduled that the RBS 100 analyzes to determine usage criteria.

Postponing Scheduling Decision In one embodiment, the decision about whether a computer job should be allowed to use a particular resource may be postponed. For example, a particular computer job processes a specified number of requests from other computer jobs before even considering whether a resource-based scheduler should schedule a particular computer job You may have usage criteria that allow you to In one embodiment, the RBS suspends execution of certain computer jobs when resource utilization exceeds a threshold. A particular computer job specifies the number of requests from other computer jobs that can be processed before scheduling a particular computer job. In one embodiment, after that number of requests has been processed, a particular computer job is then scheduled. In another embodiment, after the request is processed, the RBS determines whether to allow a particular computer job to have resources.

  In one embodiment, the resource-based scheduler has a normal worklist for resource requests that should be satisfied without delay and a deferred worklist for resource requests that can be deferred. Each item in the deferral list may be stamped with the current request number when the request is on the deferral list. These deferred requests may be ordered based on which deferred requests should be processed first. In one embodiment, there are multiple deferred worklists. When the RBS decides to initiate a new request, the RBS first looks at the deferred list against the regular list to see if any requests have expired, and then gets them next. obtain.

Resource Based Scheduling Worklist In one embodiment, the RBS 100 has a resource based scheduling worklist 120 for each resource that can be scheduled for use by a computer job. For example, the RBS 100 has a CPU resource work list 120 (1), a disk I / O work list 120 (2), a network I / O work list 120 (3), and other resource work lists 120 (n). Examples of other resource work lists include, but are not limited to, network resource work lists, video resource work lists, keyboard resource work lists. Each work list 120 includes a job waiting to use a resource corresponding to the resource. To avoid obscuring the diagram, a scheduling worklist based on all possible resources is not shown in FIG. 1A. In one embodiment, the specific work list is for a computer job that utilizes a combination of resources. In one embodiment, there are two or more worklists for a particular resource, each worklist corresponding to a different priority. For example, a computer job with a high priority enters a work list, and a computer job with a medium priority enters another work list. Worklists may or may not be ordered.

  In one embodiment, RBS 100 determines which worklist to place the computer job based on an analysis of executable code 108. For example, in one embodiment, RBS 100 examines instructions in the executable code 108 of a computer job to determine what resources the computer job requires.

  In one embodiment, if a sufficient amount of computer resources are available, the RBS 100 provides resources to one of the computer jobs in the work list corresponding to the resources. For example, the scheduling logic 112 selects one of the computer jobs on the work list based on the available capacity of the resource and the computer job usage criteria. Other selection criteria can be used. Selection criteria include the order in which jobs were added to the worklist, computer job priority (eg, process priority, thread priority), and matching of available resource capacity to job resource needs, It is not limited to these. The selection may be based on any combination of these criteria and other criteria not specifically described.

Resource Based Scheduler Without Resource Based Scheduling Worklist In one embodiment, RBS 100 does not use scheduling worklists corresponding to various computer resources. Referring to FIG. 1B, RBS 100 receives requests to continuously schedule computer jobs in a non-specific order. For example, if an application wants to run a computer job, it sends a request to the RBS 100 to schedule one or more computer jobs. The RBS 100 determines or is notified of which resource a particular computer job uses. Examples of resources include processor 304, storage device 310, display 312, input device 314, and network communication interface 318, and network resource 182 accessed via network 184.

  The RBS 100 determines or is notified about the use of a particular resource. The RBS 100 also determines or is notified about the usage criteria that the computer job has regarding a particular resource. Based on specific resource usage and usage criteria, the RBS 100 determines whether a specific computer job should be scheduled to use the specific resource. For example, if the use of the network communication interface 318 meets the computer job usage criteria, the RBS 100 schedules the computer job to be executed using the network communication interface 318. If the use of the network communication interface 318 does not meet the computer job usage criteria, the RBS 100 does not schedule the computer job to use the network communication interface 318. Rather, the RBS 100 may wait and schedule a computer job when the use of the network communication interface 318 meets the computer job usage criteria.

Resource prioritization In one embodiment, computer resources are prioritized for scheduling purposes. For example, CPU, disk I / O, network I / O, and other resources may be ranked based on the relative speed of the resources. For example, disk I / O may be referred to as a slower resource than a CPU resource and may therefore be given higher priority. Similarly, network I / O resources may be faster than disk I / O but slower than the CPU. Thus, network resources will be given higher priority than the CPU but less than disk I / O. If RBS 100 takes into account slower resources and schedules these resources with higher priorities, the delay of faster resources such as CPUs can be minimized.

Application-based example The following is an example of resource-based scheduling in an application. As an example, the application may be a defragmentation program or a virus scanner. In this example, computer job A is at the top of disk I / O scheduling worklist 120 (2), has a utilization standard of 60% disk I / O available capacity, and disk I / O scheduling worklist 120. (2) Computer job B, which is the next above, has a usage criterion of 20% disk I / O available capacity. If the disk I / O has 30% available capacity, RBS 100 will not schedule computer job A. This is because the disk I / O does not have a sufficient usable capacity. However, computer job B could be scheduled. The RBS 100 then uses 30% disk I / O available capacity by scheduling an appropriate computer job (computer job B) to use instead of wasting disk I / O. If RBS 100 provided disk I / O resources to computer job A requiring 60% disk I / O, this may have caused a computer job conflict. This is because more than 200% of disk I / O resources would have been allocated.

Scheduler Based on Kernel Level Resources In one embodiment, RBS 100 is implemented in O / S at the kernel level. In such an embodiment, kernel level RBS 100 has sufficient knowledge of the entire work list of computer jobs (eg, threads) requesting execution. Therefore, the RBS 100 can order execution based on resource availability without having to determine the usage rate of any resource. This is because the RBS 100 has already completely controlled the scheduling of various resources. There is no need for measurement, and the RBS 100 already knows what to allocate resources as is.

Process Flow FIG. 2 is a flowchart illustrating the steps of a process 200 for resource-based scheduling according to an embodiment of the invention. The steps of process 200 are described in a specific order for convenience of explanation. However, the steps may be performed in a different order. Further, the steps may be repeated many times. In step 202, RBS 100 receives usage criteria for one or more jobs. For example, an application program provides usage criteria to the RBS 100. An application can specify different criteria for different computer jobs. Applications do not need to specify usage criteria for computer jobs.

  The application controls the resource usage by sending parameters to the RBS 100 according to an embodiment of the present invention. Control of resource utilization includes, but is not limited to, disk I / O, CPU and network. For example, an application can request execution of a computer job until any combination of the above three resource threshold levels or other resources are obtained. In addition, applications can specify different resource threshold levels for different computer jobs. For example, the application specifies a different resource threshold level for each computer job according to one embodiment. Therefore, subdivided resource management is possible.

  In step 204, the RBS 100 determines usage criteria for one or more jobs. In one embodiment, the RBS 100 determines the expected usage of a particular resource by the computer job and the usage criteria is based on the expected resource usage. In one embodiment, RBS 100 determines the expected use of a particular computer job by examining instructions in the particular computer job. In one embodiment, the RBS 100 bases the expected usage on a stored value that represents the previous usage of the resource by a particular computer job.

  In step 206, the computer job is added to a resource-based scheduling worklist. For example, a particular process or at least a thread of a particular process is placed on a scheduling worklist based on at least one resource. As more jobs are requested to be scheduled, they are added to a resource-based scheduling worklist. In one embodiment, requests from many different computer jobs are placed on the work list. In one embodiment, the request can be satisfied by a computer job that is scheduled to utilize a particular resource. In one embodiment, computer jobs are inserted at a location on the work list based on computer job priority. In one embodiment, the order in which the threads of a process execute may be important, so that computer jobs (eg, threads) are placed on the work list to maintain the desired execution order.

  In step 208, specific computer resources are selected to be utilized. For example, the RBS 100 may determine that a computer resource that is referred to as slower should have a higher priority. As a specific example, RBS 100 selects a disk I / O resource. However, the choices include thread flow, computer job priority (eg, process priority, thread priority), number of jobs (eg, threads) awaiting execution on each worklist, and job (eg, thread or Based on other factors such as the availability of other resources required by the process.

  In step 210, the RBS 100 determines the use of the selected computer resource. Utilization may be based on usage over recent intervals. For example, usage may be based on any convenient criteria such as the latest “x” quantum or a recent period. However, usage need not be based on intervals. For example, utilization may be based on the number of operations waiting to be executed at a particular time.

  When the RBS 100 calculates resource usage, according to one embodiment of the present invention, what is measured is the resource usage of jobs other than those associated with a particular application. This will be described using the following example in which the CPU usage threshold is set to 20%. If the CPU usage is less than 20% before enabling the computer job associated with a particular application, the CPU usage may increase above 20% when the computer job is executed. This increase over 20% is not considered a CPU resource utilization violation in this example. Similar principles may apply to network, disk I / O resources, and other resources.

  In one embodiment, RBS 100 estimates the utilization of selected computer resources over future time intervals. The RBS 100 may estimate future usage based on recent usage of resources. As a specific example, recent utilization of network I / O is measured (or otherwise learned). Based on recent network I / O usage, an estimate of network I / O usage in the near future is made. The estimation may be based on other factors.

  In step 212, the RBS 100 selects one of the computer jobs on the work list corresponding to the selected resource. The RBS 100 schedules the selected computer job for execution to use the selected computer resource. The RBS 100 makes a selection based on the usage criteria of at least one of the usage of the specific resource and the computer job on the work list for the specific computer resource. For example, if the usage of a selected resource is 60% and the usage criteria for a particular computer job is that the selected resource has less than 40% usage, the particular computer job is not scheduled. This is because the usage standard is not satisfied. In this case, if the usage criteria allow the selected resource to have 60% usage, the RBS 100 will be able to select another computer job and schedule that computer job.

  By repeating at least some of the steps of process 200 to schedule computer jobs one by one, the RBS determines the scheduling order for the computer jobs.

  In step 214, the RBS 100 stores resource usage information for the computer job just executed. The RBS 100 may use this resource usage information later to determine the usage criteria for the computer job.

Micro Job In one embodiment, RBS 100 schedules a micro job. In one embodiment, the size of a microjob is the size that a particular microjob can complete within the allotted time that owns the resources used to execute the processing job. In one embodiment, each microjob is sized to complete within its allotted time. However, some microjobs may be too large to complete execution within their allotted time.

  In one embodiment, the allocation time is quantum. A quantum is a time slice that is given to a portion of computer code (eg, a thread) and during which that portion of the code owns CPU resources. Different operating systems use different quanta. Further, the quantum allocated to a particular code portion can change based on the situation during execution time. For example, O / S may increase or decrease the size of the quantum allocated to a thread. In one embodiment, a computer job is divided into microjobs based on the quantum size expected to be assigned to the computer job. In another embodiment, a computer job is divided into microjobs based on the quantum size assigned to the computer job. The decision as to which part of a computer job should be divided as a microjob can be made either before or during execution time.

  A microjob, according to one embodiment, can be completed as a single unit while safely allowing for a pause in execution until the next microjob is executed, substantially smaller (eg, minimal) work Unit. Having a safe pause in execution means that the execution of a particular microjob can be delayed without affecting the results that result from the execution of all microjobs.

  A micro job can be part of a thread. For example, a thread can be divided into multiple microjobs. These microjobs can be scheduled in the same way that threads are scheduled. However, as described above, in one embodiment, a microjob will complete execution if it can execute over the quantum or other period of time it owns processing resources.

  Microjobs can require very little resources (eg, CPU time, memory allocation) at any point in time. Because it uses such minimal resources at any point in time, it can be an invisible process. Keeping microjobs small reduces the amount of computer resources that a computer job uses at one time. Thus, according to one embodiment of the present invention, the execution of microjobs consumes a sufficiently small amount of resources so as not to significantly affect the performance of other applications in the computer system.

Exemplary API
An embodiment of the present invention is an API that allows an application to specify various resource utilization parameters. In one embodiment, RBS 100 has something like an API. An application can use APIs to specify usage criteria for computer jobs (eg, processes, threads, microjobs, or other code portions). The exemplary API has the following resource threshold parameters for CPU, disk, and network.

CPU usage threshold Hold disk I / O count threshold Network usage threshold The above parameters may be specified for each computer job. For example, for computer jobs that use the network, a network threshold may be used. However, for computer jobs that do not use the network, the network threshold may be zero. Thus, according to an embodiment of the present invention, granular resource management is provided.

  As a specific example, an application may require a particular computer job to run only if CPU utilization is less than 50%, I / O disk utilization is less than 40%, and network traffic is less than 60%. . Any combination of resource threshold factors can be used, including nothing at all. The CPU usage threshold varies from one RBS CPU usage to another, according to embodiments of the invention, as opposed to any other job usage threshold.

The following two parameters are used to specify the interval at which usage should be measured.
CPU usage window Network usage window The CPU usage window parameter defines the time window over which CPU usage is calculated. For example, CPU utilization over the last n milliseconds is averaged. The network usage window defines a time window over which network usage is calculated. These parameters may be inherent in the RBS 100. However, the application can override these parameters. The pending disk I / O is absolute at any point in time and therefore does not need to be calculated.

  Mandatory idle time parameters can be passed from the application to the RBS to control how computer jobs are distributed over a period of time. The mandatory idle time parameter is arbitrary. Further, in use, the value of the mandatory idle parameter may be zero.

Mandatory idle time The RBS tracks the “idle time” defined as the system idle time after all computer jobs have been executed. For example, an application can use RBS to place a computer job into a work list. If there are no computer jobs in the resource-based work list 120, the RBS waits for the specified required idle time and wakes up to authorize the application to perform additional work. For example, the defragmentation program may first execute a certain number of computer jobs to defragment the disk drive and then be paused by the RBS computer job scheduler. After the specified mandatory idle time, the RBS calls a defragmentation program to authorize additional work. For example, the defragmentation program may execute a cleanup job such as memory release. The mandatory idle time may be a default parameter that can be adjusted by the application.

  The following parameters relate to waiting for a computer job to run when resource utilization exceeds a threshold.

Wait time Maximum wait time If the RBS determines that the resource usage is currently too high to execute the computer job, the RBS waits for the specified wait time before reconfirming the resource usage. The latency parameter may be increased each time the RBS determines that resource utilization is too high. For example, the RBS can increase the latency parameter until the maximum latency is reached. These parameters can be specified by the application when the application is first started. The application can adjust these parameters during runtime.

  The exemplary API uses time (eg, milliseconds) to specify various parameters, but other criteria such as quantum may be used.

Variations In one embodiment, RBS 100 is part of an operating system. In another embodiment, RBS 100 is a stand-alone application that facilitates scheduling of computer jobs for other applications. In yet another embodiment, RBS 100 is integrated into an application program and schedules for that particular application. For example, the RBS 100 may be integrated into a disk defragmentation program or a virus detection program.

  If the RBS 100 is run outside of the operating system, the RBS 100, in one embodiment, is self-limiting in its resource usage. For example, the RBS 100 monitors its resource usage and if its resource usage becomes too high, the RBS 100 requests the operating system to stop scheduling the RBS 100 for a period of time.

Yet another example The following example illustrates how the RBS 100 may operate. However, the RBS 100 need not operate as described in these examples. As an example, RBS 100 schedules multiple computer jobs for a particular application. Some of these computer jobs may require disk I / O. The RBS 100 may analyze disk usage as a condition for scheduling computer jobs. If the disk usage is too high, the RBS 100 waits until the disk usage falls and schedules a specific computer job for the application. The RBS 100 continues to monitor disk I / O usage and can schedule another computer job if there are no other applications seeking access to the disk I / O. However, in this embodiment, the RBS 100 cannot schedule another computer job if another application seeks to use the disk I / O. Therefore, other applications can use the disk I / O.

  As another example, RBS 100 may analyze network usage. If the network traffic is too high, RBS 100 will not schedule any computer jobs for the application until the traffic slows down. If the network traffic is low enough, RBS 100 schedules the computer job for execution. The RBS 100 continues to make sure that the network traffic remains low enough. If the network traffic remains low enough, another computer job may be scheduled. However, if the traffic gets too high, there are no other computer jobs that are scheduled to run. In these last two examples, the computer job may be a micro job. But that is not necessary.

Hardware Overview FIG. 3 is a block diagram that illustrates a computer system 300 upon which an embodiment of the invention may be implemented. The steps of process 200 are stored as instructions on one or more computer readable media of system 300 and executed on a processor of computer system 300. Computer system 300 includes a bus 302 or other communication mechanism for communicating information, and a processor 304 coupled with bus 302 for processing information. Computer system 300 also includes a main memory 306, such as random access memory (RAM) or other dynamic storage device, coupled to bus 302 for storing information and instructions to be executed by processor 304. Main memory 306 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by processor 304. Computer system 300 further includes a read only memory (ROM) 308 or other static storage device coupled to bus 302 for storing static information and instructions for processor 304. A storage device 310, such as a magnetic disk or an optical disk, is provided and coupled to the bus 302 for storing information and instructions. Computer system 300 may have any number of processors 304. For example, in one embodiment, computer system 300 is a multiprocessor system. The processor 304 may have any number of cores. In one embodiment, processor 304 is a multi-core processor 304. The computer system 300 can be used in a hyper thread machine.

  Computer system 300 may be coupled via bus 302 to a display 312 such as a cathode ray tube (CRT) for displaying information to a computer user. Coupled to the bus 302 is an input device 314 that includes alphanumeric characters and other keys for communicating information and command selections to the processor 304. Another type of user input device is a cursor control 316 such as a mouse, trackball, or cursor direction key for communicating direction information and command selections to the processor 304 and for controlling cursor movement on the display 312. It is. The input device typically has two degrees of freedom in two axes, a first axis (eg, x) and a second axis (eg, y), which allows the device to specify a position in the plane. can do.

  The invention is related to the use of computer system 300 for implementing the techniques described herein. According to one embodiment of the invention, these techniques are performed by computer system 300 in response to processor 304 executing one or more sequences of one or more instructions contained in main memory 306. . Such instructions can be read into main memory 306 from another machine-readable medium, such as storage device 310. Execution of the sequence of instructions contained in main memory 306 results in processor 304 performing the process steps described herein. In an alternative embodiment, the present invention may be implemented using a wired circuit configuration instead of or in combination with software instructions. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

  The term “machine-readable medium” as used herein refers to any medium that participates in providing data that causes a machine to operation in a specific fashion. In an embodiment implemented using computer system 300, various machine-readable media are included, for example, in providing instructions for execution to processor 304. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks such as storage device 310. Volatile media includes dynamic memory, such as main memory 306. Transmission media includes coaxial cable, copper wire and optical fiber, including wiring with bus 302. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications. All such media need to be specific so that the instructions carried by the medium can be detected by a physical mechanism that reads the instructions into the machine.

  Common forms of machine-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, or any other magnetic medium, CD-ROM, any other optical medium, punch Card, paper tape, any other physical medium with a pattern of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, carrier wave as described later, or computer therefrom Includes any other medium that can be read.

  In carrying one or more sequences of one or more instructions for execution to processor 304, various forms of machine-readable media may be included. For example, the instructions may initially be carried on a remote computer magnetic disk. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 300 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infrared detector can receive the data carried in the infrared signal and appropriate circuitry can place the data on the bus 302. Bus 302 carries the data to main memory 306, from which processor 304 retrieves and executes the instructions. The instructions received by main memory 306 may optionally be stored on storage device 310 either before or after execution by processor 304.

  Computer system 300 also includes a communication interface 318 that is coupled to bus 302. Communication interface 318 provides a two-way data communication coupling to network link 320 that is connected to local network 322. For example, communication interface 318 may be an integrated services digital network (ISDN) card or modem for providing a data communication connection to a corresponding type of telephone line. As another example, communication interface 318 may be a local area network (LAN) card for providing a data communication connection to a compatible LAN. A wireless link may also be realized. In any such implementation, communication interface 318 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

  Network link 320 typically provides data communication to other data devices through one or more networks. For example, the network link 320 may provide a connection to a host computer 324 through a local network 322 or to a data device operated by an Internet service provider (ISP) 326. ISP 326 then provides data communication services through a wide area packet data communication network now commonly referred to as the “Internet” 328. Local network 322 and Internet 328 both use electrical, electromagnetic or optical signals that carry digital data streams. Signals through various networks, as well as signals on network links 320 that carry digital data to and from computer system 300 and through communication interface 318 are exemplary forms of carriers that carry information.

  Computer system 300 can send messages and receive data, including program code, through the network, network link 320 and communication interface 318. In the Internet example, the server 330 may send request codes for application programs over the Internet 328, ISP 326, local network 322 and communication interface 318.

  The received code may be executed by processor 304 upon receipt and / or stored in storage device 310 or other non-volatile storage for later execution. In this manner, the computer system 300 can obtain application code in the form of a carrier wave.

  In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, what is the invention and what uniquely and exclusively indicates that the applicant intends to be an invention is a set of claims arising from this application, including any subsequent corrections, and Such claims are in a specific form. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Accordingly, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.

Claims (41)

A method realized by a machine,
Determine whether the specific computer job should be scheduled to use the specific resource based on the usage of the specific resource and the usage criteria associated with the specific computer job for the specific resource A method comprising the steps of:   The method of claim 1, further comprising determining an expected usage of the particular resource by a computer job, wherein the usage criteria is based on the expected usage.   The method of claim 2, wherein the step of determining expected usage includes examining instructions in the computer job. The step of determining the expected usage is:
Accessing a value representing a previous use of the particular resource by the computer job;
3. The method of claim 2, comprising: basing the expected usage on a stored value representing previous usage.   The method of claim 1, further comprising receiving the usage criteria from an application program that owns a computer job.   The method of claim 1, further comprising submitting the computer job to at least one of a scheduling worklist based on a plurality of resources.   For each of a plurality of computer jobs scheduled for execution, the method further comprises: placing the computer job on at least one of a scheduling worklist based on a plurality of resources corresponding to the plurality of computer resources; The method of claim 1, wherein the scheduling worklist based on comprises computer jobs awaiting use of a given computer resource.   The method of claim 7, further comprising selecting a particular computer resource to be utilized by one of the plurality of computer jobs.   The method of claim 1, wherein the step of determining whether the particular computer job should be scheduled to utilize the particular resource is performed by an operating system.   The method of claim 1, wherein the step of determining whether to schedule the particular computer job to utilize the particular resource is performed by a scheduler based on resources external to the operating system. .   The method of claim 1, further comprising determining usage of the specific resource.   The method of claim 1, further comprising estimating an expected utilization of the particular resource over an interval.   The step of determining whether the particular computer job should be scheduled to utilize the particular resource is based on expected utilization of the particular resource and the utilization criteria over the interval. Item 13. The method according to Item 12.   The step of determining whether the particular computer job should be scheduled to utilize the particular resource is further associated with the particular computer job with respect to other resource utilization and other resources. The method of claim 1, based on usage criteria.   The method of claim 1, wherein the use of the specific resource is based on a time of use of the specific resource.   The method of claim 1, wherein utilization of the specific resource is based on a number of usage requests for the specific resource. A method realized by a machine,
Placing each of the plurality of computer jobs on at least one of a plurality of resource-based scheduling worklists corresponding to the plurality of computer resources, each of the scheduling worklists based on a given resource comprising: Including a computer job having usage criteria for the given resource, the method further comprising:
Selecting a particular computer resource to be utilized by one of the plurality of computer jobs;
The computer job to use the specific computer resource based on the usage criteria of at least one of the computer jobs on the worklist for the specific computer resource and the use of the specific computer resource Selecting one of the methods.   The method of claim 17, further comprising assigning a priority to each of the plurality of computer resources.   The method of claim 18, wherein the step of selecting a particular computer resource to be utilized by one of the plurality of computer jobs is based on the priority assigned to each of the plurality of computer resources. Method.   The method of claim 18, wherein assigning priorities to the plurality of computer resources is based on a relative speed of the plurality of computer resources.   The step of selecting one of the computer jobs to utilize the specific computer resource is further prioritized to at least one of the computer jobs on the work list for the specific computer resource. 18. The method of claim 17, based on. Selecting one of the computer jobs to utilize the particular computer resource for an interval of:
Identifying one of the computer jobs on the worklist for the particular resource;
Scheduling the particular computer job for execution with the particular resource if the estimated usage of the particular resource indicates sufficient available capacity to meet the usage criteria for the particular computer job; 18. The method of claim 17, comprising:   The method of claim 17, further comprising determining an expected usage of the particular resource by a first computer job, wherein the usage criteria for the first computer job is based on the expected usage. .   24. The method of claim 23, wherein the step of determining expected usage includes examining instructions in the first computer job. The step of determining the expected usage is:
Accessing a value representing a previous use of the particular resource by the first computer job;
24. The method of claim 23, comprising: basing the expected usage on a stored value representing previous usage.   The method of claim 17, further comprising receiving the usage criteria from an application that owns a first computer job.   The method of claim 17, wherein selecting one of the computer jobs to utilize the specific computer resource is performed by an operating system.   The method of claim 17, wherein the step of selecting one of the computer jobs to utilize the particular computer resource is performed by a scheduler based on resources external to the operating system.   The method of claim 17, further comprising determining usage of the particular resource.   The step of determining whether the particular computer job should be scheduled to utilize the particular resource further includes the use of another resource and the usage associated with the particular computer job with respect to other resources. The method of claim 17, based on criteria.   A computer-readable medium for carrying one or more sequences of instructions, wherein the one or more sequences of instructions are executed by one or more computer processors to utilize a particular resource and the particular resource Determining whether the particular computer job should be scheduled to utilize the particular resource based on usage criteria associated with the particular computer job for the one or more computer processors. A computer readable medium to be executed.   The step of determining whether the particular computer job should be scheduled to utilize the particular resource is further associated with the particular computer job with respect to other resource utilization and other resources. 32. The method of claim 31, based on usage criteria. A system,
One or more computer processors;
A computer-readable medium communicatively coupled to the one or more computer processors, wherein the computer-readable medium stores one or more stored sequences of instructions, the one or more instructions The stored sequence of, when executed by the one or more computer processors, the specific resource based on usage of the specific resource and usage criteria associated with the specific computer job for the specific resource A system that causes the one or more computer processors to execute a step of determining whether the particular computer job should be scheduled to utilize.   The step of determining whether the particular computer job should be scheduled to utilize the particular resource is further associated with the particular computer job with respect to other resource utilization and other resources. 34. The method of claim 33, based on usage criteria. A method realized by a machine,
Receiving requests from a plurality of computer jobs, each request requiring utilization of a particular resource to satisfy the request, the method further comprising:
Determining a scheduling order for the computer job to use the specific resource based on the use of the specific resource and a usage criterion of each of the computer jobs regarding the specific resource; Method.   At least a portion of the request requires the use of another resource to satisfy the request, and the step of determining a scheduling order for the computer job to use the specific resource further relates to other resources 36. The method of claim 35, based on usage criteria possessed by the computer job associated with the portion of the request.   36. The method of claim 35, wherein usage of the specific resource is based on a time of use of the specific resource.   36. The method of claim 35, wherein utilization of the specific resource is based on a number of requests that require utilization of the specific resource to satisfy the request.   36. The method of claim 35, wherein the step of determining a scheduling order for the computer job to utilize the particular resource is performed by an operating system.   36. The method of claim 35, wherein the step of determining a scheduling order for the computer job to utilize the particular resource is performed by a scheduler based on resources external to the operating system. A method realized by a machine,
Receiving requests from a plurality of computer jobs, each request requiring utilization of one or more of a plurality of resources to satisfy the request, the method further comprising:
Selecting specific resources to schedule computer jobs for use;
The computer job that requires the use of the specific resource based on the usage criteria of each of the computer jobs that require the use of the specific resource and the use of the specific resource with respect to the specific resource Determining a scheduling order for.