Shared Resources on Multicore Processors - Case Study Example

Shared Resources on Multicore Processors findings on memory contention Zhuravlev, Blagodurov, & Federova (1) state that, multicore processors have become more of the rule than the exception, due to limitations that have staggered the development of large single cores and made the multicore systems the likely future of computing. Zhuravlev et al. (12) feel that "contention for shared resources on multicore processors remains an unsolved problem in existing systems despite significant efforts dedicated to this problem in the past." Therefore, (Federova, Blagodurov, & Zhuravlev 25) sought to carry out tests to identify the best schedules. As a result, they ran a group of applications on different schedules, paired differently such that each application had the opportunity to pair with the other applications. Fedorova et al(2) found out that when applications are assigned to cores according to the best possible schedule, the workload as a whole performed better when paired and individually Blagodurov, Zhuravlev, Dashti and Federova (1) include that modern multicore processors use non uniform access lattices. In that regard Blogodurov et al. (1) found out that "contention occurs when memory intensive threads are scheduled together in cores that share the same memory domain" They (Blogodurov et al., nd) indicate that a memory scheduler should separate competing threads to eradicate contention for shared resources. 2. Analysis of schedule used to test applications. Federova et al. (29) paired the given applications into schedules so that they share the same memory domains to attain three possible schedules. (1) (soplex, sphinx), (Gamess, Namd) (2) (Sphinx, Gamess), (Soplex,Namd) (3) (Sphinx, Namd), (Soplex,Gamess) In this case, the assumption was that none of the applications share the same data since if they did share then the argument is that they would access shared resources comparatively. They state that if the applications are denoted A,B,C,D, the scheduler would result in three possible schedules. 1. {(A,B), (C,D)} 2. {(A,C), (B,D)} 3. {(A,D), (B,C)} where (A,B) means that threads A and B share the same memory domain. Fedorova et al. (6) states that the best schedule may be determined by the pain metric constructed via actual memory reuse profiles or by approximating the pain metric using unlike data. They state that upon realization of the best possible schedule, the performance of the workload needs to be determined. They computed the pain of all the schedules Schedule {(A,B), (C,D)}: Pain=Average ( pain(A,B), pain(C,D) ) Schedule {(A,C), (B,D)}: Pain=Average ( pain(A,C), pain(B,D) ) Schedule {(A,D), (B,C)}: Pain=Average ( pain(A,D), pain(B,C) ) They ran each possible schedule in the same memory domain rather than as an individual entity. In doing this they managed to attain the actual degradation of each bench mark while sharing the same memory domain as another bench mark. They then compared the actual best schedule with the estimated best schedule, that is they compared the degradation of the estimated best schedule in relation to the actual best one. They concluded that high-rate-miss applications should not be combined with low-rate-miss applications. 3. Cache contention and its causes. Federova et al.(3) states "cache contention occurs when two or more threads are assigned to run on the cores of the same memory domain. In this case, the threads share the same LLC." Zhuravlev et al.(2) adds that previous works meant to improve thread performance in multicore systems was based on cache contention as it was assumed that it was the main, if not the only cause of performance degradation. They also state that (Zhuravlev et al. 20) "in this context cache contention is suffering extra cache misses because its co-runner (threads running on cores that share the same LLC) bring their own data into the LLC evicting the data of others." As stated by (Federova et al. 45) when a thread requests a cache line that doesnt exist, then a cache miss is registered, and a new cache line must be allocated. Another reason that results with cache contention is when an application suffers extra cache misses due to its pairing applications bringing their own data into the LLC evicting the data of others. Chandra, Guo, Kim and Salihin (nd, p1) indicate that the sharing of a cache by threads in multicore processors is important to prevent redundancy. However, when several threads share the same cache, they compete for the available cache space. The sharing of cache space isnt uniform and therefore, the performance of those threads that access less cache space is greatly reduced. 4. Contention avoidance methods. Federova et al. (32) have throughout the analysis aim to prove that the best formula to avoid contention in multicore processor systems is by building a contention-aware scheduler. They state that assigning applications to cores depending on the best possible schedule, may result in an increase in the performance of threads sharing the same memory domain. These schedules can be determined by contention aware algorithms. Their approach involves coming up with tests with applications sharing the same memory domain to determine the best and worst performances of applications either paired or as an individual to determine best schedules. They state that having the actual degradation may enable the determination of the best schedule. The measured performance is given as the ratio of the average degradation to the solo execution for all bench marks. Federova et al. (11) also state that those high miss rate applications should be kept apart, that is they should not be paired in the same schedule that shares the same memory domain Zhang, Dwarkadas, and Shen (nd) indicate that multicore processors present new challenges in sharing resources. Threads that compete for the same cache space can result in sub-optimal performance if the threads are executed simultaneously. They therefore recommend that the available control system to the operating system in order to effect cache partitioning is page coloring. They state that it has been used to improve cache utilization, improve on chip network traffic and demonstrate cache partitioning. Zhuravlev et al.(2010, p.3) also support that the best policy to control contention for shared resources in multicore processors is by using an algorithm that is guaranteed to find an optimal scheduling assignment. On the other hand (Blagodurov et al., nd) states that contention for shared resources in multicore processors occurs when memory intensive threads are co-scheduled. Therefore, they recommend that "a contention-aware scheduler separates competing threads onto separate memory hierarchy domains to eliminate resource sharing and, as a consequence, to mitigate contention." Works cited Blagodurov, S., zhuravlev,S., Dashti, M., Fedorova, A.(nd). A case for NUMA-aware contention management on multicore systems. Web. Chandra, D., Guo, F., Kim, S., & Solihin, Y. (nd). Predicting inter-thread cache contention on a chip multi-processor architecture. North Carolina. Web. Fedorova, A., Blagodurov, S., Zhuravlev, S. Managing contention for shared resources on multicore processors.2009. Print Zhang,X., Dwarkadas,S., Shen, K.,(nd). Shared resource control in multi-core processors. Web. Zhuravlev, S., Blagodurov, S., Fedorova, A. Addressing shared resources contention in multicore processors via scheduling. Pittsburg, Pennsylvania, U.S.A. 2010. Web.< https:/www.cs.sfu.ca/.../asplos212.>. Read More