Managing contention for Shared Resources on Multicore Processors

This “Case Study” cover information on computer systems with multicore processors which can increase performance by running applications of various types (models) and methods. This paper focuses on applications using distributed architecture, cache contention, prefetching hardware and more. Current and future contentions are discussed. Managing contention for shared resources on multicore processors are discussed in this assignment.

Explanations given for causes of contention.Discussion of the author’s testing of applications, building of prototypes and more. The discussion of architecture software and hardware as well as methods to avoid and other alternatives and solutions (Fedorova, Blagodurov & Zhuravlev, 2006; 2009). Estimate the authors’ findings. The findings of the author’s will be listed below and they are based on the groups from the three test that the authors performed, in which they ran group applications several times on three different schedules and every time with two pairings that shared a memory domain.The pairs consisted of the following Soplex and Sphinx was ran in a memory domain, while Gamess and Namd shared another memory domain and then Sphinx was paired with Namd, and Soplex was paired and ran with Gamess together.

Then a contrast was done on each application with its worst performance, in which the performance levels indicated in the terms of percentage and degradation from solo execution times and the bottom line or the test of the applications is that the lower the numbers, the better the performance (Fedorova, Blagodurov & Zhuravlev, 2006; 2009).Analyze the schedule that the authors used to test the applications using a distributed architecture. Identify which schedule they believe was the best. The schedule that the authors used is the “Metric for Computing the Actual Best Schedule” and the following information show us the three different type schedules as in the supplied information for this assignment: Estimated Best Schedule {A, B}, {C, D}:DegradationEST = Average (Degrad (A|B), Degrad (B|A), Degrad (D|C) DegradationAct = Average (Degrad (A|C), Degrad (C|A), Degrad (B|D), Degrad (D|B) Degradation over actual best = (DegradationEST – 1) * 100% DegradationAct As stated in the supplied information from the information given it shows how to construct estimated best and actual best schedules for any four application workload on a system with two memory domains so long as actual pair-wise degradation for any pair of applications have been obtained on the experimental system.This can be used for systems with a larger number of memory domain. In the information supplied in figure 6 the representation showcases the results obtained using their semi-analytical methodology as well as the performance results.

While the blue bar(s) indicate the pain model, which uses memory and reuse profiles to estimate “Pain” and find the best schedule (the method that was set) for figure 4. The red bar(s) indicates the approximate “Pain”, which is for a given application running with another is estimated with the aid of data that is obtain from online.After the estimation of pain, then the method in figure 4 can used. The green bar(s) shows the smallest results, which are considered as the “Actual Best Schedule” and according to the information supplied the smaller the numbers shows the best schedule (Fedorova, Blagodurov & Zhuravlev, 2006; 2009). Evaluate the author’s findings with regard to cache contention.

Explain what causes contention for the cache.The author’s findings with regard to cache contention are as follows: Was where they perform several experiments that were aimed to isolate and quantify the degree of contention for various types of shared resources, such as cache, memory controller, front-side bus, and prefetching hardware per the information supplied for this assignment. The authors arrived at the following findings;As it turns out the contention for the shared cache is the phenomenon, consist of competing threads ending up convicting each other’s’ cache lines from the cache, which is not the main cause of performance degradation experienced by competing applications on multicore systems such as those in figure 6. Contentions for other shared resources, such as the front-side bus, prefetching resources, and memory controller are the dominant cause for performance degradation such as shown in figure 7. Due to the limitations of existing hardware counter, it was difficult to separate the effects of contention for prefetching hardware and effects of additional contention for the memory controller and front-side bus caused by prefetching per the information supplied for this assignment.(Fedorova, Blagodurov & Zhuravlev, 2006; 2009; Tam, Azimi, Stumm, 2007).

Analyze the contention avoidance methods proposed by the authors for the cache, memory controller, front-side bus (FSB), and prefetching hardware as the distributed architecture. Prefetching and its impact shows the combined effect of the above three listed three factors and is only an upper bound on the impact of contention for prefetching hardware itself.This is the reason why the older memory-reuse model that was designed to model cache contention only, was not effective in our environment This model was evaluated by the authors on a simulator that did not model contention for resources other than shared cache and it turns out that when applied to a real system that other contentions are present the model did not prove effective. On the other hand, cache miss rate turned out to be an excellent predictor for contention for the memory controller, prefetching hardware, and front-side bus, with each application in the author’s model was co-scheduled with “Milc” application to generate contention.An application that issue many cache-misses will occupy the memory controller and the front-side bus so it not only hurt other applications that use that hardware, but, end up suffering itself if this hardware is usurped by others.

The investigation by the authors of contention-aware scheduling algorithms delivered a lesson to them that high-miss-rate applications must be kept apart. This means that they should not be scheduled in the same memory domain.Some restrictions have already suggested this approach, it is not well understood why using the miss rate as a proxy for contention ought to be effective, especially the fact that it contradicts the theory behind the popular memory-reuse model The authors from the information given feel that based on their findings should help put an end to the above listed controversy; furthermore, based on the new knowledge, they built a prototype of contention-aware scheduler that measures the miss rates of online threads and decides how to place threads on cores based on that information.The prototype that was built of contention-aware scheduler for multicore systems called DIO (Distributed Intensive Online).

The DIO scheduler distributes intensive applications’ across memory domains (by intensive we mean those with high LLC miss rates) after measuring online applications miss rates. Another prototype scheduler, called Power DI (Power Distributed Intensity), is intended for scheduling applications in the workload across multiple machines in a data center per the information supplied for this assignment.The feasibility of this is to save power and use less systems without hurting and/or affecting the performance; also, in figure 8 shows the performance results of workloads of these two schedulers. With the two schedulers listed above there have been great strides and improvements and they appear to make a difference even more so in conserving power, consumption , workload running on multiple machine, in the data center(s) power saving by clustering, even though there may be some issues due to clustering (double edge sword) due to competition for shared system resources.There is a metric that takes into account both energy consumption and performance of the workload is the EDP (energy-delay-product).

Power DI works as follows: massing a centralize scheduler has acknowledge the entire infrastructure and distributes incoming applications on as few machines as possible, worth the exception of memory-intensive applications.These applications are not scheduled on the same memory domain unless the other applications has a very low cache miss rate thus a low memory intensity.(Fedorova, Blagodurov & Zhuravlev, 2006; 2009; Chandra, Guo, Kim, and Solihin, 2005; Suh, Devadas, & Rudolph, 2002; Tam, Azimi, Stumm, 2007). Conclusion: This paper covered the valid and feasible information on contention for shared resources that significantly impedes the efficiency and effectiveness of operation multicore systems, new methods for mitigating contention via scheduling algorithms as well as other sources of contention from cache, memory controller, front-side bus, workloads, poor performance, high priority, saving power without having to make sacrifices without hurting the processes and more.