Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-25 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4-5, 10-11, 16, 20-21 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Kuraishi (US 20150067689 A1) in view of Weinman (US 20130219407 A1).
Regarding claim 1, Kuraishi teaches:
An apparatus, the apparatus comprising interface circuitry, machine-readable instructions, and processing circuitry to execute the machine-readable instructions to: (Claim 1. A job scheduling system configured to schedule job execution timings for a job in a computing system; the job scheduling system comprising:)
receive a request to execute a task on a computing system. ([0052] The job information receiving module 12 is configured to receive job information defining a job pending execution in the computing system, the job information including an indication of computing hardware resources required to execute the job, and an indication of an allocation of application licenses required to execute the job.)
receive a requirement of the task for usage of a resource of the computing system; and. ([0052] The job information may be submitted by a user. Alternatively or additionally, the job information may be based on a request submitted by a user having been received at the computing system separately and been subjected to processing in preparation for submission to the job information receiving module 12 as job information. The job may be a batch job, and the job information may be provided as a batch job script 140.[0053] The job information receiving module may be configured to perform processing on the received job information, for example, to extract certain data or indications from the job information. The job information may be received in units so that one single unit of job information corresponds to one job, for example, one batch job script 140 per job. Alternatively, job information may be provided as data from which the job information receiving module 12 is configured to identify the individual jobs and extract the requirements per job. In terms of requirements, the job information receiving module 12 may be configured to extract from the job information an indication of the computing hardware resources required to execute a particular job and the application licenses required to execute a particular job. An indication may be explicit details of the hardware resources or application licenses, or may be data which allow the explicit details to be sought, for example, from a lookup table. Furthermore, the job information may include an indication of a timing (either absolute or relative to the present time or time of receipt) by which the job is to be completed, or alternatively a timing by which the job is to be started.)
schedule execution of the task by reserving at least part of the resource for the execution of the task based on the requirement. ([0055] The job execution scheduler 14 is operable to receive a job, or information describing a job, which is pending execution in the computer system. The job execution scheduler 14 is operable to determine a timing at which each job is to be executed. For example, it may be that the job execution scheduler 14 stores a list of jobs pending execution, and determines when to move a job from the pending list to be run. At the determined timing, it may be that certain job information is submitted to a node responsible for executing the job, or for coordinating execution of the job by submitting inputs arguments to applications and receiving outputs. The job execution scheduler 14 is configured to wait until both the indicated application licenses and the indicated computing hardware resources are available before running a job. [0056] The job execution scheduler 14 may be configured to reserve and acquire hardware resources and application licenses on behalf of a job, and schedule timing of the job at such a time as the hardware resources and application licenses are available. The job execution scheduler 14 may operate in cooperation with a license scheduling module 16 and a hardware scheduling module 18. The hardware scheduling module 18 is configured to reserve the indicated computing hardware resources on behalf of the job. The form of that reservation depends on the computing system within which the embodiment is implemented. For example, it may be that once the job execution scheduler receives job information of a pending job, the hardware scheduling module 18 is informed of the computing hardware resource requirements indicated in the job information, and is configured to communicate with computing hardware resources directly, or with operating systems or computing resource controllers, to determine if and/or when the indicated computing hardware resources are available. It may be that if they are available immediately, the hardware scheduling module 18 effectively holds the available resources on behalf of the job, so that the resources are not available to other applications or jobs. Alternatively, it may be the hardware scheduling module 18 is configured to enter into queuing arrangements to wait for the required hardware resources and to secure (that is, acquire and hold) them on behalf of the job when they become available.)
Kuraishi does not appear to explicit teach: wherein the requirement indicates a data-throughput bound limitation for the task and wherein reserving at least part of the resource comprises reserving a portion of a shared interconnect link based on the data- throughput bound limitation.
However, Weinman teaches: [0086][0096] In step 201, a job is submitted. Metadata concerning the job, such as priority, start time, required completion times, environment/resource characteristics/capabilities/capacity required, access bandwidth characteristics, and the like may be provided as part of this metadata, or optionally in certain alternate embodiments, determined from the metadata provided. [0122] Each job may be associated with a job transport capacity requirement; all the costs may be set to zero so that the job scheduler (150) cooperates with the validity portion so as to determine at least one node that is able to run the at least one job; and the system may also have a link manager (140) configured to reserve at least some of the link capacity of at least one of the links connected to the one or more of the nodes where the job is scheduled, such that a resulting reserved link capacity matches or exceeds the job transport capacity requirement. [0021] Each link may have capacity that may be subdivided into logical links with corresponding bandwidth allocations for different purposes. For example, a physical capacity of 10 gigabits per second may be allocated as 10 gigabits to customer or application A, or possibly 2 gigabits per second to customer A and 8 gigabits per second to customer B, or 1 gigabit per second to each of 10 customers or applications, and so forth. See also [0024] [0087][0122].
Accordingly, it would have been obvious to modify Kuraishi’s resource based job scheduling system to further consider and reserve communication link capacity based on job’s bandwidth requirement as taught by Weinman. Kuraishi teaches scheduling a job based on availability and reservation of job required computing resources, while Weinman teaches that job requirements may include access bandwidth and transport capacity and that corresponding link capacity is reserved to meet the job transport capacity requirement. One would have been motivated to make such a combination to ensure that sufficient communication bandwidth, in addition to computing resources, is available for execution of the scheduled job.
Regarding claim 4, Kuraishi teaches:
The apparatus of claim 1, wherein the instructions comprise instructions to determine an availability of the resource and schedule execution of the task based on the determined availability. ([0055] The job execution scheduler 14 is operable to receive a job, or information describing a job, which is pending execution in the computer system. The job execution scheduler 14 is operable to determine a timing at which each job is to be executed. For example, it may be that the job execution scheduler 14 stores a list of jobs pending execution, and determines when to move a job from the pending list to be run. At the determined timing, it may be that certain job information is submitted to a node responsible for executing the job, or for coordinating execution of the job by submitting inputs arguments to applications and receiving outputs. The job execution scheduler 14 is configured to wait until both the indicated application licenses and the indicated computing hardware resources are available before running a job. [0056] The job execution scheduler 14 may be configured to reserve and acquire hardware resources and application licenses on behalf of a job, and schedule timing of the job at such a time as the hardware resources and application licenses are available. The job execution scheduler 14 may operate in cooperation with a license scheduling module 16 and a hardware scheduling module 18. The hardware scheduling module 18 is configured to reserve the indicated computing hardware resources on behalf of the job. The form of that reservation depends on the computing system within which the embodiment is implemented. For example, it may be that once the job execution scheduler receives job information of a pending job, the hardware scheduling module 18 is informed of the computing hardware resource requirements indicated in the job information, and is configured to communicate with computing hardware resources directly, or with operating systems or computing resource controllers, to determine if and/or when the indicated computing hardware resources are available. It may be that if they are available immediately, the hardware scheduling module 18 effectively holds the available resources on behalf of the job, so that the resources are not available to other applications or jobs. Alternatively, it may be the hardware scheduling module 18 is configured to enter into queuing arrangements to wait for the required hardware resources and to secure (that is, acquire and hold) them on behalf of the job when they become available. See also [0065])
Regarding claim 5, Kuraishi teaches:
The apparatus of claim 1, wherein the requirement indicates at least one of a desired value of the resource to be provided for the execution of the task and a desired time for completion of the task. ([0069] An exemplary batch job script 140 is illustrated in FIG. 4. The exemplary batch job script 140 comprises three sections: resource definition 142, environment settings 144, and ISV apps execution 146. The resource definition section 142 includes an indication of the computing resources a job requires to run.)
Regarding claim 10, Kuraishi teaches:
The apparatus of claim 1, wherein the instructions comprise instructions to: receive a further request to execute a further task on the computing system; receive a further requirement of the further task for usage of a resource of the computing system; and schedule execution of the further task by reserving at least part of the resource for the execution of the further task based on the further requirement of the further task and the requirement of the task. ([0061] FIG. 3 illustrates the exemplary architecture of FIG. 2, with the job scheduler 120 and IJMS 100 illustrated in more detail. A particular example of the IJMS 100 is illustrated in which the IJMS 100 operates as a daemon, that is to say, a process which is transparent to the user and does not require user input to function. In this particular example, the IJMS daemon 100 is configured to launch proxy license servers 130, one per job, in order to hold the required licenses on behalf of the job. The proxy license servers 130 may also be configured to communicate with the real license servers 300 in order to check for availability of, reserve, and/or acquire licenses on behalf of the job. The job scheduler 120 includes three functional portions or modules, which exemplify the functionality that may be provided by such a job scheduler 120. The job scheduler 120 comprises a pre-check portion 122, a batch job script execution portion 124, and a post-check portion 126. The IJMS daemon 100 and the job scheduler 120 are processes running on a head node 110. [0062] The dotted lines in FIG. 3 represent the principle interactions between process or components. The hard lines represent interconnections, and it can be seen that the head node 110 acts as an access point by which users 400 can access the infrastructure and applications of the computing nodes 200. The IJMS daemon 100 via the proxy license servers 130 provides a mechanism to reserve and acquire application licenses from the real license servers 300 on behalf of a job. The job scheduler 120 is responsible for reserving computing resources 210 on behalf of the job and coordinating execution of the job at a timing when the required application licenses have been acquired and the required computing resources are available.)
Regarding claim 11, Kuraishi teaches:
The apparatus of claim 10, wherein the further requirement further indicates an at least temporary exclusive usage of the resource, and wherein the instructions comprise instructions to schedule execution of the task and the further task based on the temporary exclusive usage of the resource. ([0056] The job execution scheduler 14 may be configured to reserve and acquire hardware resources and application licenses on behalf of a job, and schedule timing of the job at such a time as the hardware resources and application licenses are available. The job execution scheduler 14 may operate in cooperation with a license scheduling module 16 and a hardware scheduling module 18. The hardware scheduling module 18 is configured to reserve the indicated computing hardware resources on behalf of the job. The form of that reservation depends on the computing system within which the embodiment is implemented. For example, it may be that once the job execution scheduler receives job information of a pending job, the hardware scheduling module 18 is informed of the computing hardware resource requirements indicated in the job information, and is configured to communicate with computing hardware resources directly, or with operating systems or computing resource controllers, to determine if and/or when the indicated computing hardware resources are available. It may be that if they are available immediately, the hardware scheduling module 18 effectively holds the available resources on behalf of the job, so that the resources are not available to other applications or jobs.)
Regarding claim 16, the claim recites similar limitation as corresponding claim 1 and is objected to for similar reasons as claim 1 using similar rationale.
Regarding claim 20, the claim recites similar limitation as corresponding claim 10 and is objected to for similar reasons as claim 10 using similar rationale.
Regarding claim 21, the claim recites similar limitation as corresponding claim 11 and is objected to for similar reasons as claim 11 using similar rationale.
Regarding claim 25, the claim recites similar limitation as corresponding claim 1 and is objected to for similar reasons as claim 1 using similar rationale.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Kuraishi (US 20150067689 A1) in view of Weinman (US 20130219407 A1) and further view of Fong (US 20180276044 A1).
Regarding claim 3, Kuraishi does not appear to explicit teach:
The apparatus of claim 1, wherein the shared interconnect link is at least one of a PCIe, UPI, or CXL link.
However, Fong teaches: [0016] By way of introduction of the example depicted in FIG. 1, an embodiment of a workload scheduling method 100 according to the present invention can include various steps for collecting information on workload resource requirements for execution including GPUs for offloading the computation to, matching the resource requirements with available resources in data center of machines with GPU resources, and dispatching the workload to allocated GPU, CPU and memory resources. [0019] Referring now generally to the embodiments of the invention, as depicted in FIG. 2A-C, the accelerators are attached to CPU using different mechanisms forming a topology with different communication patterns between any pair of CPU and GPUs, or between any pair of GPUs. The communication rates are not identical. For example, if two GPUs can communication via only one PCIe switch (e.g., GPU 1 and GPU2 are attached to PCIe switch 1, in FIG. 2A), they can transfer data without copy through any CPU, and without interfering other PCIe switchs (switches 2, 3 and 4), enjoying the highest bandwidth. However, if two GPUs are directly attached to different PCIe switches, their communication needs to go through the two directly attached switches, and a third switch that connects the previous two switches (e.g., GPU 1 has to go through switch 1, switch 2 and switch 5 to copy to GPU 5), competing bandwidth with other GPUs. In the worst case, if two GPUs are attached to PCIe switches which are connected to different CPUs, their communication needs to go through not only switches but also[0020] CPUs, consuming the bandwidth of both PCIe switches and the inter-CPU channel (e.g., to transfer data from GPU 1 to GPU 9, GPU 1 has to go through switch 1 and switch 5 to copy data to CPU 1; CPU 1 needs to copy to CPU 2; then CPU 2 needs to copy to GPU 9 through switch 6 and switch 3). Another aspect of the topology is that, there are other type of connections such as NVLink which is faster than PCIe. In a computer cluster, we can have a mixture of PCIe and NVLink connected GPUs. See [0026-0027][0033-0036].
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify the Kuraishi-Weinman scheduling system such that the shared interconnect link is a PCIe link, as taught by Fong. Fong teaches, in a workload scheduling environment, analyzing workload communication requirements and selecting CPU/GPU resources and available communication bandwidth. A person of ordinary skill would have been motivated to implements Fong’s PCIe interconnect to provide a known high bandwidth interconnection suitable for bandwidth aware ask scheduling and resource placement.
Claims 2, 12 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Kuraishi (US 20150067689 A1) Weinman (US 20130219407 A1) and in further view of Abraham (US 20150277984 A1).
Regarding claim 2, Kuraishi does not appear to explicit teach:
The apparatus of claim 1, wherein the resource is a resource shared by a plurality of processing cores of the computing system.
However, Abraham teaches: [0025] A multithreading facility may be available on a computer system that implements a supporting architecture. The multithreading facility provides support for multithreading to enable a group of threads, which may also be referred to as CPUs, that share a core. When the multithreading facility is enabled, the CPUs within a core may share certain hardware resources such as execution units or caches. When one CPU in a core is not ready to use hardware resources (typically, while resolving data in the memory nest), other CPUs in the core can utilize the shared core resources rather than have them remain idle. When the multithreading facility is installed and enabled, a thread is synonymous with a CPU that is a member of a core. When the multithreading facility is not installed, or the facility is installed but not enabled, a core comprises a single CPU or thread.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Kuraishi’s resource scheduling system with Abraham’s teachings of a multithread/multicore sharing architecture. Kuraishi already teaches reserves computing hardware resources including CPUs and cores, while Abraham teaches that threads within a core share hardware resources. A person having ordinary skill in the art would have been motivated to include Abrahams’s teachings into Kuraishi so that the scheduler could allocate and reserve shared processor resources in a multicore, multithreaded system.
Regarding claim 12, Abraham teaches:
The apparatus of claim 10, wherein the resource is a resource shared by a plurality of processing cores of the computing system, wherein the further requirement further indicates an at least temporary exclusive usage of a processing core of the plurality of processing cores, and wherein the instructions comprise instructions to schedule execution of the task and the further task by: allocating at least one respective thread to the task and the further task on a same processing core of the plurality of processing cores; and reserving a respective part of the shared resource for the execution of the task and the further task based on the temporary exclusive usage of the processing core. ([0035] The logical core 201A supports CPU1 211 as the first logical thread and CPU2 212 as the second logical thread. Logical core 201B supports CPU3 213 as the first logical thread and CPU4 214 as the second logical thread. When a program such as program 172 becomes ready to execute, the operating system 171 dispatches program 172 on an available CPU such as CPU1 (logical thread 211) on logical core 201A. When program 173 becomes ready to execute, the operating system 171 dispatches program 173 on an available CPU such as CPU2 (logical thread 212) on logical core 201A. The LPAR hypervisor 163 then dispatches the entire logical core 201A onto a single physical core 102, such as, for example, onto core 1 110. Corel 110 is configured to execute simultaneous multithreading using two threads which are the threads 111 and 112, such that CPU1 (logical thread 211) executes on physical thread 111 while CPU2 (logical thread 212) executes on physical thread 112. When dispatching a logical core 201 to a physical core 102, the LPAR hypervisor 163 is restricted to the rule that only one logical core 201 is dispatched to a single (hardware) physical core 102 at a time. This means that while logical core 201A is dispatched and executing on core1 110, the logical cores 201B-F cannot be executing on core1 110 (at that same time), and therefore, no logical threads (CPUs) for logical cores 201B-F can execute on the core1 110 during this time. Since guest OS 171 controls what two logical threads, CPU1 211 and CPU2 212, are assigned to the logical core 201A during multithreading, the guest OS 171 consequently controls physical thread 111 and physical thread 112 executing on physical core1 110, because the LPAR hypervisor 163 assigns the whole logical core 201A to (exclusively) run on the physical core1 110 at this point in time. At a later point in time, a different logical core 201 (such as logical core 201D) can be assigned to run on the core1 110 under the same rule.) Refer to claim 2 for the motivation to combine.
Regarding claim 22, the claim recites similar limitation as corresponding claim 12 and is objected to for similar reasons as claim 12 using similar rationale.
Claims 6-9, 13-15, 17-19 and 23-24 are rejected under 35 U.S.C. 103 as being unpatentable over Kuraishi (US 20150067689 A1) and Weinman (US 20130219407 A1) and in view of Balasubramanian (US 20210004276 A1).
Regarding claim 6, Kuraishi does not appear to explicit teach:
The apparatus of claim 1, wherein the requirement indicates at least one of a desired range of a value of the resource to be provided for the execution of the task and a desired time interval for completion of the task, wherein the instructions comprise instructions to dynamically reschedule execution of the task based on the at least one the desired range of the resource and the desired time interval.
However, Balasubramanian teaches: ([0021] Illustrated processing block 42 provides for automatically determining a first proposed change to an existing resource allocation associated with a first application (e.g., existing workload, instance, VM, tenant, etc.) in a first node (e.g., of a server rack). In the illustrated example, the first proposed change is determined at least partially based on a requested resource allocation (e.g., SLA) associated with a pending application (e.g., incoming tenant) and a first tolerance associated with the first application. In an embodiment, the first tolerance includes a migration tolerance parameter (e.g., indicating a tolerance to application migration), a frequency tolerance parameter (e.g., operating frequency range, minimum and/or target), a memory bandwidth (BW) tolerance parameter (bandwidth, minimum and/or target), a cache size tolerance parameter (e.g., cache size range, minimum and/or target), a thermal design power (TDP) tolerance parameter (e.g., TDP range, minimum and/or target), an instructions per clock (IPC) tolerance parameter (e.g., IPC range, minimum and/or target), etc., or any combination thereof. Moreover, the first proposed change may include a reduction to the existing resource allocation and/or a migration of the first application to a second node. The decision to migrate an application across nodes may result in application tolerances (e.g., RDT settings) migrating along with the application. [0029] Illustrated processing block 62 conducts the requested resource allocation (e.g., associated with the pending application) on the first node. In an embodiment, block 62 includes reducing a processor operating frequency, allocating a portion of the memory bandwidth to the pending application, allocating a portion of the cache to the pending application, and so forth. Additionally, block 64 may activate the pending application on the first node. The method 60 therefore further enhances performance by dynamically adjusting resource allocations. See also [0032])
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Kuraishi’s scheduler to use Balasubramanian’s resource allocation ranges and dynamic adjustment techniques. Kuraishi already schedules jobs on required hardware resources. A person having ordinary skill in the art would have been motivated to include Balasubramanian’s teachings of dynamically adjusting allocations in response to resource requirements into Kuraishi to improve scheduling flexibility under changing resource conditions to satisfy job demands.
Regarding claim 7, Balasubramanian teaches:
The apparatus of claim 1, wherein the requirement indicates at least one of a processing frequency, a memory bandwidth, a cache size, a processor characteristic, an interconnect latency and an accelerator configuration. ([0021] Illustrated processing block 42 provides for automatically determining a first proposed change to an existing resource allocation associated with a first application (e.g., existing workload, instance, VM, tenant, etc.) in a first node (e.g., of a server rack). In the illustrated example, the first proposed change is determined at least partially based on a requested resource allocation (e.g., SLA) associated with a pending application (e.g., incoming tenant) and a first tolerance associated with the first application. In an embodiment, the first tolerance includes a migration tolerance parameter (e.g., indicating a tolerance to application migration), a frequency tolerance parameter (e.g., operating frequency range, minimum and/or target), a memory bandwidth (BW) tolerance parameter (bandwidth, minimum and/or target), a cache size tolerance parameter (e.g., cache size range, minimum and/or target), a thermal design power (TDP) tolerance parameter (e.g., TDP range, minimum and/or target), an instructions per clock (IPC) tolerance parameter (e.g., IPC range, minimum and/or target), etc., or any combination thereof. Moreover, the first proposed change may include a reduction to the existing resource allocation and/or a migration of the first application to a second node. The decision to migrate an application across nodes may result in application tolerances (e.g., RDT settings) migrating along with the application.) Refer to claim 6 for the motivation to combine.
Regarding claim 8, Balasubramanian teaches:
The apparatus of claim 1, wherein the instructions comprise instructions to: receive a tolerance for migration of the execution of the task; and in response to determining a constraint of the resource, reschedule the execution of the task by reserving a further part of the resource for the execution of the task based on the requirement and the tolerance for migration. ([0031] Illustrated processing block 72 determines a second proposed change to an existing resource allocation associated with a second application (e.g., existing workload, instance, VM, tenant, etc.) in the second node. In one example, the second proposed change is determined at least partially based on the existing resource allocation associated with the first application and a second tolerance associated with the second application. The second tolerance may include a migration tolerance parameter, a frequency tolerance parameter, a BW tolerance parameter, a cache size tolerance parameter, a TDP tolerance parameter, an IPC tolerance parameter, etc., or any combination thereof. In an embodiment, block 74 issues the second proposed change to the second application, where a determination is made at block 76 as to whether the second application has accepted the second proposed change. If so, block 78 conducts the second proposed change, which may include a reduction to the existing resource allocation of the second application and/or a migration of the second application to a third node. Block 76 may also override the second proposed change and bypass block 78 if untrusted code is detected. Illustrated block 79 issues one or more additional proposed changes to one or more corresponding applications in the second node if the second proposed change is not accepted by the second application. If one of the additional proposed changes is accepted by a corresponding application (e.g., a winning bidder), the additional proposed change may be automatically conducted. See also [0021-0025]) Refer to claim 6 for the motivation to combine.
Regarding claim 9, Balasubramanian teaches::
The apparatus of claim 1, wherein the instructions comprise instructions to: schedule the execution of the task by further reserving at least part of a processing core of a plurality of processing cores of the computing system for the execution of the task based on the requirement; receive a tolerance for migration of the task to a further one of the plurality of processing cores; and in response to determining a constraint of the processing core, reschedule the execution of the task by reserving a further processing core of the plurality of processing cores for the execution of the task based on the requirement and the tolerance for migration. ([0021] Illustrated processing block 42 provides for automatically determining a first proposed change to an existing resource allocation associated with a first application (e.g., existing workload, instance, VM, tenant, etc.) in a first node (e.g., of a server rack). In the illustrated example, the first proposed change is determined at least partially based on a requested resource allocation (e.g., SLA) associated with a pending application (e.g., incoming tenant) and a first tolerance associated with the first application. In an embodiment, the first tolerance includes a migration tolerance parameter (e.g., indicating a tolerance to application migration), a frequency tolerance parameter (e.g., operating frequency range, minimum and/or target), a memory bandwidth (BW) tolerance parameter (bandwidth, minimum and/or target), a cache size tolerance parameter (e.g., cache size range, minimum and/or target), a thermal design power (TDP) tolerance parameter (e.g., TDP range, minimum and/or target), an instructions per clock (IPC) tolerance parameter (e.g., IPC range, minimum and/or target), etc., or any combination thereof. Moreover, the first proposed change may include a reduction to the existing resource allocation and/or a migration of the first application to a second node. The decision to migrate an application across nodes may result in application tolerances (e.g., RDT settings) migrating along with the application. See also [0031-0033]). Refer to claim 6 for the motivation to combine.
Regarding claim 13, Balasubramanian teaches:
The apparatus of claim 10, wherein the instructions comprise instructions to: in response to determining a constraint of the resource, negotiate, with at least one of the task and the further task, a modification of at least one of the requirement and the further requirement for mitigating the constraint; and reschedule the execution of at least one of the task and the further task based on the negotiated modification. ([0039] In block 102, the RDT negotiates with the existing instances/applications. If the negotiation fails, the method 96 returns to block 99. If the negotiation is successful, block 103 determines whether the proposed change involves a migration of an existing instance/application. If so, another node (e.g., Node N in FIG. 4B) is selected and the method 96 returns to block 99. If the proposed change does not involve a migration, block 104 updates the CLoS of the existing instance/application and block 105 spins-up the requested instance with the negotiated RDT. See also [0021] and [0026]. Refer to claim 6 for the motivation to combine.
Regarding claim 14, Balasubramanian teaches:
The apparatus of claim 1, wherein the instructions comprise instructions to enforce the scheduled execution of the task based on the reserved part of the resource. ([0038] FIG. 7 shows a method 96 of negotiating RDT profile configurations and enforcing newly negotiated RDT profile configurations. The method 96 may generally be incorporated into blocks 94 and/or 95 (FIG. 6), already discussed. More particularly, the method 96 may be implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium such as RAM, ROM, PROM, firmware, flash memory, etc., in configurable logic such as, for example, PLAs, FPGAs, CPLDs, in fixed-functionality logic hardware using circuit technology such as, for example, ASIC, CMOS or TTL technology, or any combination thereof.[0039] A user may issue a request to spin-up an instance and/or application at block 97 with QoS=func(Frequency, Cache, Mem-BW, Power, IPC, Migration-tolerance), where the request is validated at block 98. If the request is invalid, the illustrated method 96 prompts the user for a valid request and returns to block 97. If the request is valid, block 99 performs an availability check (e.g., to find a free machine willing to negotiate). If no availability is detected at block 99, illustrated block 100 triggers a component such as a BMC and/or a manageability engine (ME) to take policy-based action. Otherwise, block 101 negotiates with the platform RDT (e.g., mapping CLoS and/or RMID). In block 102, the RDT negotiates with the existing instances/applications. If the negotiation fails, the method 96 returns to block 99. If the negotiation is successful, block 103 determines whether the proposed change involves a migration of an existing instance/application. If so, another node (e.g., Node N in FIG. 4B) is selected and the method 96 returns to block 99. If the proposed change does not involve a migration, block 104 updates the CloS of the existing instance/application and block 105 spins-up the requested instance with the negotiated RDT.) Refer to claim 6 for the motivation to combine.
Regarding claim 15, Balasubramanian teaches:
The apparatus of claim 14, wherein the instructions comprise instructions to enforce the scheduled execution of the task by configuring the resource based on the requirement. ([0037] Illustrated processing block 91 provides for determining whether AnRDT is supported. If not, the illustrated method 90 terminates. If AnRDT is supported, block 92 determines that a new higher priority application (App) and/or guest is being considered to be scheduled by the orchestrator. In such a case, a whitelist manifest verification is triggered (e.g., “kicked off”). Block 93 determines whether the verification was successful. If not, the illustrated method 90 terminates. Otherwise block 94 exposes the current CLoS, RMID and/or TDP configuration to verified applications and/or guests. Based on available guests/apps and/or orchestrator guidelines, the platform negotiates RDT profiles. In an embodiment, block 95 enforces the newly negotiated configuration and the method 90 terminates.) Refer to claim 6 for the motivation to combine.
Regarding claim 17, the claim recites similar limitation as corresponding claim 6 and is objected to for similar reasons as claim 6 using similar rationale.
Regarding claim 18, the claim recites similar limitation as corresponding claim 8 and is objected to for similar reasons as claim 8 using similar rationale.
Regarding claim 19, the claim recites similar limitation as corresponding claim 9 and is objected to for similar reasons as claim 9 using similar rationale.
Regarding claim 23, the claim recites similar limitation as corresponding claim 13 and is objected to for similar reasons as claim 13 using similar rationale.
Regarding claim 24, the claim recites similar limitation as corresponding claim 14 and is objected to for similar reasons as claim 14 using similar rationale.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, LEWIS BULLOCK JR can be reached at (571)272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like
assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
