Accurate ILP-Based Contention Modeling on Statically Scheduled Multicore Systems

Abstract

Commercially available Off The Shelf (COTS) multicores have been assessed as the baseline computing platform even in the most conservative real-time domains. Multicore contention arising on shared hardware resources, with its circular dependence with scheduling, is among the most challenging issues that require urgent attention before multicores can be fully embraced for real-time computing. In the context of static scheduling, still the most used scheduling approach in realtime industries, we propose an ILP formulation for computing the worst-case contention delay suffered by a task due to interference on a shared bus. Our model provides accurate contention delay bounds that avoid unnecessary over-accounting of conflicts between bus requests, by considering contention effects at system-level (i.e., across tasks) rather than at task-level only. This allows precisely capturing the interdependence between timing interference of conflicting requests, issued in parallel by other cores (tasks), and the identification of the particular set of tasks co-running on those cores. We assess our technique both analytically and empirically on a real COTS multicore platform. We show, via extensive evaluation, that jointly accounting for worst-case task overlapping and request distribution scenarios always provides tighter contention bounds when compared to state-of-the-art solutions.

Modeling Contention Interference in Crossbar-based Systems via Sequence-Aware Pairing (SeAP)

“…We build on the concept of request pairing [30] to derive the worst-case contention delay among a concrete set of tasks. Request pairing ultimately consists in the definition of a mapping between the multicore requests potentially happening simultaneously and contending for a given shared resource.…”

“…For a precise contention analysis, a preliminary system-level analysis is required to derive the set of potentially overlapping tasks and the worst-case contenting requests they can potentially generate. This analysis should take into account the specific scheduling policy as well as other execution-model concerns [8,30].…”

“…Request pairing is effective for modeling (worst-case) contention happening in multiple resources in bus-based systems [30]. However, it is essentially based on access count information only and, as seen in the illustrative example in Section I, it cannot model with sufficient tightness the contention arising in crossbar-based systems.…”

“…The contention suffered by a task depends on several aspects that need to be modeled conservatively but also as precisely as possible to avoid unnecessary pessimism. First, the number of requests generated by applications that can be typically derived by either static [32,36,9,21] or measurementbased [8,30] techniques. Second, the HSR arbiter behavior including its internal buffering and policy [32,36,9,21].…”

“…Contention analysis approaches exploiting the number of requests of applications (either total [31,36,9,21,28] or pertype [12,10,30]) are accurate for modeling HSR with mutually exclusive access, such as buses. However, building only on access counts does not allow properly modelling the behavior of those devices that support some degree of parallelism, such as the crossbar.…”