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-25 are rejected under 35 U.S.C. 103 as being unpatentable over Ge “Application-Aware Power Coordination on Power Bounded NUMA Multicore Systems” in view of Kruglick (US 20130311628 A1).
Regarding claim 1, Ge teaches:
generating the performance-based index table for the workload, wherein the performance-based index is based on a memory efficiency; (page 594, To avoid the difficulties of directly modeling the performance and power consumption of parallel application executions, we use a simple and practical model reduction approach. In this approach, we capture the impacts of different workload performance and power characteristics using three metrics: parallel scalability, memory access intensity, and components’ critical power levels.)
building a label feature by analyzing a static program feature of the application in the group of applications and the performance-based index table wherein the static program feature of the application comprises a memory intensity of the application, wherein the memory intensity comprises an amount of memory being used above a threshold of memory usage. (page 595, Workload classification. We categorize parallel applications based on their parallel scalability and memory access intensity analyses and customize the power coordination strategy for each category. Along each characterization dimension, we label each application with one of three values: low, moderate, and high, which we have determined empirically. For example, as illustrated in Figure 5, EP belongs to the category of (high parallel scalability, low memory intensity). Page 598-599, Memory intensive applications incur large amounts of data movement from/to local and remote memory, which leads to high memory bandwidth. As shown in Figure 8(b), memory intensive applications like Kmeans and SP achieve more than 10 GB/s with half of the available cores, while compute intensive applications like EP and Dgemm involve little memory accesses. The results indicate that memory intensive applications can be further split into two subcategories. In the first subcategory, applications like SP and Stream involves large amounts of local memory accesses but minimal or no remote accesses. Because local memory accesses cause memory contention which significantly degrades performance, distributing cores to more sockets leads to higher performance than consolidating cores into one processor. In the second subcategory, applications like Kmeans and Ptrans have large ratios of remote to local memory accesses when distributing the cores to more processors. For example, remote memory accesses in Kmean can account for more than 50% of the total memory accesses. For this type applications, consolidating cores to a same processor improve both performance and power. .See also page 596, fig. 5 )
constructing, using clustering algorithms, a model for provisioning a pre-initialization environment using the label feature. (page 598 TABLE II,K means Clustering algorithm, random memory and memory intensive. See also page 598-599, Memory intensity and core affinity. )
loading, using the label feature, the applications in the group of applications into the pre-initialization environment. (page 596-597, Application Runner provides a user interface, takes a program and the problem size to be computed and the power budget as input, gets a parallel workload execution configuration (⃗a, ⃗d) from the Recommender, and creates a job script which launches the job with the execution configuration (⃗a, ⃗d) on a power-bounded NUMA multicore node through a job scheduler. Configuration Recommender implements the decision engine, which takes a tuple (program, problem, power bound) as input and returns a parallel workload execution configuration (⃗a, ⃗d) to the Application Runner.)
introducing a selection policy for a switch in a pre-initialization environment in an application to balance usage of at least one resource; and (page 592, we propose application-aware strategies that decide the optimal power and resource configuration based on applications’ characteristics, without the need of searching in the hardware and software allocation space)
Ge does not appear to explicitly teach: A computer-implemented method comprising: accepting a request from a group of applications to generate a performance-based index table for a workload based at least in part on a feature of the applications; and updating input to the model in response to monitoring a traffic of requests and collecting runtime data of the workload, wherein updating the model comprises adjusting the model for, provisioning the pre-initialization environment.
However, Kruglick teaches: [0029] The allocation module 106 may be configured to receive an instruction to deploy the distributed application 110. Such an instruction may be submitted by a user. For example, the user may click on an icon to deploy the distributed application 110 through a graphical user interface. Such an instruction may also be submitted by another application or a system command. Upon receiving the instruction to deploy the distributed application 110, the allocation module 106 may be configured to determine, for each of the modules 112, eligible nodes of the nodes 104 that are capable of executing the module based on the diversity table 108. Each of the modules 112 may contain program code that can be executed only by nodes having certain functional capabilities. That is, each of the modules 112 may require or utilize a particular runtime environment for proper and/or optimized execution of the module. The particular runtime environment may include particular hardware, software, firmware, and/or other suitable elements (e.g., a particular operating system or virtual machine, a certain amount of memory, a certain processor speed, etc.). In this case, the eligible nodes may refer to at least a subset of the nodes 104 having those functional capabilities, as defined by the diversity table 108, matching the particular runtime environment. [0051] In some embodiments, the combination of probes 412A-412B, gauges 414A-414B, and controllers 416A-416B may be configured to gather and analyze fault predictive data in order to determine fault indicators 418. The probes 412A-412B may be configured to gather and report raw data from the nodes 404A-404B to the gauges 414A-414B. The probes 412A-412B may refer to individual sensors attached to or associated with the modules 112A-112B. In this case, the probes 412A-412B may be additional program code inserted into the modules 112A-112B for purposes of gathering and reporting the raw data generated when the nodes 404A-404B execute the modules 112A-112B. The raw data may include any suitable information regarding the activities and states of the nodes 404A-404B when executing the modules 112A-112B. [0055] Upon receiving the recommended deployment changes 422 from deployment optimization module 408, the deployment module 406 may effectively transfer the video decompression software module from the node 404B to the node 404N. In some embodiments, the deployment module 406 may adjust the original deployment strategy 420 in order to generate a modified deployment strategy 424 based on the recommended deployment changes 422. The deployment module 406 can then redeploy the modules 112 according to the modified deployment strategy 424. In some other embodiments, the deployment module 406 may adjust the diversity table 108 to account for the fault indicators 418. For example, the diversity table 108 may further include fault data that specifies probabilities of failure of certain nodes when executing certain modules. In this way, the allocation module 106 can avoid or minimize deploying modules to certain nodes that have higher probabilities of failure. The deployment module 406, the deployment optimization module 408, and the fault prediction module 410 may continuously operate in order to dynamically modify the deployment of the modules 112 in the distributed application 110.
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 Ge and Kruglick before them, to include Kruglick’s monitoring and deployment optimization modules in Ge’s application aware coordination system. One would have been motivated to make such a combination to dynamically adapt initially selected resources configuration to changing runtime conditions thereby improving system reliability and maintaining efficient processor and memory utilization.
Regarding claim 2, Ge teaches:
The computer-implemented method of claim 1, wherein the resource of the pre- initialization environment comprises space, memory, and speed. (page 593, Hardware and Power Resource Allocation Our power allocation framework treats power as a type of resource. For a given parallel workload consisting of multiple concurrent tasks (either MPI processes or OpenMP threads), our framework not only allocates hardware resources including the number of processor sockets and cores for its execution, and but also allocates power among the participating hardware that concurrently execute the workload. page 596, Step 3: decide the number activated cores and core frequencies. The algorithm uses two CPU power control knobs — concurrency and core speed — to allocate processor power among the cores based on the application’s characteristics. If the application is scalable, the algorithm firstly attempts to activate as many cores as the power budget allows and then runs the cores at higher speed if possible. The rationale is that concurrency can best reserve performance and power efficiency for such applications. For applications that are poorly scalable, the scheduler firstly attempts to run activated cores at the highest frequency and then activates more cores if the power budget allows. For applications with moderate scalability, the algorithm simultaneously determines the target concurrency and core speed to match the applications’ memory intensity and parallel scalability.)
Regarding claim 3, Ge teaches:
The computer-implemented method of claim 1, further comprising providing a manager to support scaling of the pre-initialization environment based on collection of runtime data of the workload. (Page 596, As illustrated in Figure 6, coordinator includes a data-driven execution configuration training and recommender system, a user interface and application runner, and several helper tools to provide a user-friendly power-bounded computing environment.)
Regarding claim 4, Ge teaches:
The computer-implemented method of claim 3, wherein scaling comprises at least one of inserting, updating, and deleting the pre-initialization environment. (page 597, In coordinator, Recommender finds a workload execution configuration (⃗a, ⃗d) using two mechanisms. First, it queries the knowledge base for known (program, problem, power bound) combinations. If no entry is found, Recommender consults ConfigTrainner, which uses the scheduling strategy described in Section V to create a set of initial configurations but switches to a learning mode to create new configurations once coordinator collects actual performance data for the initial configurations.)
Regarding claim 5, Ge teaches:
The computer-implemented method of claim 1, wherein adjusting the model for provisioning the pre-initialization environment comprises increasing a size of the pre- initialization environment. (page 596, Step 3: decide the number activated cores and core frequencies. The algorithm uses two CPU power control knobs — concurrency and core speed — to allocate processor power among the cores based on the application’s characteristics. If the application is scalable, the algorithm firstly attempts to activate as many cores as the power budget allows and then runs the cores at higher speed if possible.)
Regarding claim 6, Ge teaches:
The computer-implemented method of claim 1, wherein adjusting the model for provisioning the pre-initialization environment comprises decreasing a size of the pre- initialization environment. (page 594, These two vectors, ⃗a and ⃗d, are used in our framework to allocate the hardware and power resources for workload execution. They together determine a parallel workload execution environment configuration e = {⃗a, ⃗d}. Note that an inactivated core, i.e., ak,i =0, will transition to its lowest power state to save power.)
Regarding claim 7, Ge teaches:
The computer-implemented method of claim 1, wherein adjusting the model for provisioning the pre-initialization environment comprises deleting the pre-initialization environment. ([0054] The deployment optimization module 408 may recommend deployment changes 422 to the deployment module 406 based on the fault indicators 418. Continuing the previously described illustrative implementation of the original deployment strategy 420, the node 404A may execute the first module 112A, and the node 404B may execute the second module 112B. In this example, the second module 112B may be a video decompression software module. The original deployment strategy 420 may have originally specified that the node 404B execute the video decompression software module because the node 404B had greater capability of performing video decompression than the node 404N. The fault indicators 418 may indicate a high risk of failure of the node 404B when executing the video decompression software module due to a low memory condition (e.g., an undesirable rate of memory change, a congested video buffer, etc.) on the node 404B. In this case, the deployment optimization module 408 may recommend the deployment changes 422 to the deployment module 406 whereby the video decompression software module is removed from the node 404B. The deployment changes 422 may suggest deploying the video decompression software to the node 404N, which does not experience the low memory condition.)
Regarding claim 8, Ge teaches:
The computer-implemented method of claim 1, wherein adjusting the model for provisioning the pre-initialization environment comprises creating the pre-initialization environment. (Application Runner provides a user interface, takes a program and the problem size to be computed and the power budget as input, gets a parallel workload execution configuration (⃗a, ⃗d) from the Recommender, and creates a job script which launches the job with the execution configuration (⃗a, ⃗d) on a power-bounded NUMA multicore node through a job scheduler.)
Regarding claim 9, Ge teaches:
The computer-implemented method of claim 1, wherein a static program features of the application comprises sorting applications using an intensity of input/output operations of the application, a memory efficiency of the application and an actual response time of the application. (page 594, B. Memory Access Intensity While the number of cores n can be determined from scalability, core affinity and memory power will be determined with application’s memory access patterns. In this work, we characterize parallel workload memory access patterns using memory access intensity, which is reflected with local memory access bandwidth, remote memory access bandwidth, and the memory power consumption.)
Regarding claim 10, Ge teaches:
The computer-implemented method of claim 1, further comprising predicting using an artificial intelligence algorithm, a usage of the pre-initialization environments by applying a program feature and a resource across the program features. (Configuration Recommender implements the decision engine, which takes a tuple (program, problem, power bound)as input and returns a parallel workload execution configuration (⃗a, ⃗d) to the Application Runner. If no entry is found, Recommender consults ConfigTrainner, which uses the scheduling strategy described in Section V to create a set of initial configurations but switches to a learning mode to create new configurations once coordinator collects actual performance data for the initial configurations.)
Regarding claim 11, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Regarding claim 12, Kruglick teaches:
The computer program product of claim 11, wherein the stored program instructions are stored in a computer readable storage device in a data processing system, and wherein the stored program instructions are transferred over a network from a remote data processing system. ([0018] FIGS. 7 and 8 are schematic diagrams illustrating computer program products)
Regarding claim 13, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 14, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 15, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 16, the claim recites similar limitation as corresponding claim 10 and is rejected for similar reasons as claim 10 using similar teachings and rationale.
Regarding claim 17, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Regarding claim 18, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 19, the claim recites similar limitation as corresponding claim 10 and is rejected for similar reasons as claim 10 using similar teachings and rationale.
Regarding claim 20, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 21, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Regarding claim 22, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 23, the claim recites similar limitation as corresponding claim 10 and is rejected for similar reasons as claim 10 using similar teachings and rationale.
Regarding claim 24, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Regarding claim 25, the claim recites similar limitation as corresponding claim 10 and is rejected for similar reasons as claim 10 using similar teachings and 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
Prosecution Insights