Resource Sharing and Partitioning in Multicore

Transcription

1 Resource Sharing and Partitioning in Multicore Francisco J. Cazorla Mixed Criticality/Reliability Workshop HiPEAC CSW Barcelona May 2014

2 Transition to Multicore and Manycores Wanted or imposed transition? Deal with the multicore paradox (well, one of them ) Want: benefits of sharing to improve average performance Don t want: problems brought by sharing to provide time bounds Opportunity: Integrating multiple applications onto the same hardware platform advantages in performance, production costs, and reliability Threat: Software performance becomes unpredictable and hard to analyzable Challenge: Prove that all temporal constraints will be satisfied during operation in a critical system 2

3 Hardware Resource Sharing (HRS): The problem Contention in the access to shared resources affects the execution time, and WCET estimates, of corunning tasks Varies across resource types: Stateless: bus Statefull: cache 3

4 Time composability shapes how HRS is handled Composability: Attained whenever a property can be determined for each element of a system isolation, and that property does not change when multiple items are brought together. Time composability The timing behavior of a software component observed, by analysis or measurement, in isolation, is not affected by the presence of other software components. Benefits in achieving incremental verification 4

5 Time composability shapes how HRS is handled TC Execution Times The execution time of a software component observed in isolation is not affected by the presence of other components TC WCET estimates The WCET bound derived for a software component in isolation is not affected by the presence of other components Normalized Execution Time of A 2,5 2 1,5 1 0,5 0 Task A Task A, B Task A, C Task A, B, C WCET Workloads 5

6 Contention in Hardware Shared Resources (HSR) Access time to HSR: Isolation: multicore: and are history dependent Depend on previously executed and active requests Vary from request to request Stateless resources (Bus): arbitration policy Statefull resources (Cache): bank conflicts Content conflict Approach: Derive bounds to and Solutions provide different design points in the tightness - complexity in the analysis time composability space 6

7 Multiple criticalities (dual) and : Non real-time tasks real-time tasks Real-time tasks real-time tasks Non real-time tasks Transparent execution: real-time tasks Hardware designs preventing non real-time tasks from affecting real-time tasks Split long-latency operations into small interruptible micro-operations Real-time tasks real-time tasks 7

8 Stateless resources: Time-dependent bounds Time sharing of the resource The load that the of contenders put on the resource does not affect a given task WCET estimate TDMA TDMA window size = N contenders * SlotSize Non work conserving Bounds to can be effectively computed Introduce complexities in the timing analysis tool depends on the particular relative cycle in which a request is ready Tighter results when the exact access cycle(s) for each request are known 8

9 Stateless resources: History-independent bounds Bounds are valid for any history of execution Round Robin arbitration 1 Bounds to can be effectively computed Introduce no complexities in the timing analysis tool What about pessimism? Low access frequency to the bus Low impact of on exec. time High frequency of access to the bus is not overly pessimistic if the load on the bus is high is pessimistic when the other tasks have low bus usage I assume that I am the last in the round-robin arbitration but other tasks access very seldom the bus Use prioritized round-robin (grouping) 9

10 Illustrative example Requestors split into g groups Each group g i contain n i tasks RR: Across tasks in each group Across groups Each task in a group has (g i x n i ) -1 contenders t 1 t 3 t 4 t 5 t 2 t 6 t 7 t 8 Groups/Tasks Delta (1,1,1,1,1,1,1) 7 (1,1,1,5) 3 19 (1,2,5)

11 Statefull resources: Combined Analysis & partitioning Mainly for shared last-level caches (LLC) Arb bank conflict Acc hard to track! History dependence is long! Combined analysis: Extending STA to determine which accesses hit/miss in cache Shift in the execution invalidates the analyses. Breaks time composability Cache partitioning Software: coloring (set partitioning) Hardware: Columnization (way partitioning) or Bankization (set partitioning) 11

12 Probabilistic Timing Analysis Replacing deterministic approaches with probabilistic ones Get rid of the need (and cost) of the detail design knowledge required to causally model the timing behavior of all system resources o. Principle: Make resource latency can be accurately captured with a probabilistic law 12

13 Probabilistic shared cache Given two tasks accessing a shared cache the features that shape their interference are: Time deterministic cache: Memory mapping of tasks as it determines the sets accessed Access frequencies of each tasks affects LRU state Relative order of accesses affect LRU state Time Randomised cache: Memory mapping of tasks Miss frequencies of tasks (Hits do not affect cache state) Relative order of accesses 13

14 Probabilistic cache Idea 1 : In Time Randomised caches limiting how often a task can evict lines from LLC is enough to derive trustworthy and tight WCET estimate Controlling LLC miss frequency No need to physically partition the cache Cache as a capacity Resource 1 Mladen Slijepcevic, Leonidas Kosmidis, Jaume Abella, Eduardo Quinones, Francisco J. Cazorla Time-Analysable Non-Partitioned Shared Caches for Real-Time Multicore Systems In Design Automation Conference (DAC) San Francisco, CA. June,

15 Probabilistic cache Idea 1 : In Time Randomised caches limiting how often a task can evict lines from LLC is enough to derive trustworthy and tight WCET estimate Controlling LLC miss frequency No need to physically partition the cache Cache as a capacity Resource 1 Mladen Slijepcevic, Leonidas Kosmidis, Jaume Abella, Eduardo Quinones, Francisco J. Cazorla Time-Analysable Non-Partitioned Shared Caches for Real-Time Multicore Systems In Design Automation Conference (DAC) San Francisco, CA. June,

16 On-Chip Resources vs Off-Chip Resources On-chip resources: Less visible and malleable from the SW High access frequency (nano seconds) Contention captured in the WCET analysis Access bounds Combined Analysis Off-chip resources: Consider no contention (or bounded) in on-chip resources Capture the impact of contention compositionally WCRT = WCET isol + offchip-contention 16

17 Challenges Manycores Abstracting internal HSR operation vs. exposing it Abstracting: History-independent access-latency bounds Simplify analysis but introduce pessimism Exposing internal operation Timing Analysis tool can benefit from execution history Tracking execution history may easily result in a state explosion Multithreaded applications Identify parallelization paradigms and how they impact WCET Parallel-application aware WCET analysis WCET-aware and parallel-application aware architecture 17

18 Resource Sharing and Partitioning in Multicore Francisco J. Cazorla Mixed Criticality/Reliability Workshop HiPEAC CSW Barcelona May 2014