Accounting for Cache Related Pre-emption Delays in Hierarchal Scheduling

Will Lunniss1Sebastian Altmeyer2Giuseppe Lipari3,4 Robert I. Davis1 1Department of Computer Science, University of York, UK {wl510, rob.davis}@york.ac.uk 2Computer Systems Architecture Group, University of Amsterdam, Netherlands altmeyer@uva.nl 3Scuola Superiore, Sant'Anna, IT g.lipari@sssup.it 4LSV – ENS Cachan, FR giuseppe.lipari@lsv.ens-cachan.fr Accounting for Cache Related Pre-emption Delays in Hierarchal Scheduling

Outline Hierarchical Scheduling Cache Related Pre-emption Delays (CRPD) Accounting for CRPD in Hierarchical Scheduling Evaluation Conclusions

Hierarchical Scheduling Hierarchical scheduling provides a means of composing multiple real-time components (applications) on a single processor Components should be isolated and not interfere with each other Divide up access to the processor using a global scheduler Schedule tasks in each component using a local scheduler

Hierarchical Scheduling Assume single processor Assume each component has a dedicated server, S, that allocates processor capacity to it Assume servers are scheduled globally using non-pre-emptive scheduler Assume tasks are scheduled locally using pre-emptive FP scheduler Each server SG, has a budget QG, and a period PG

Hierarchical Scheduling Components scheduled globally using non pre-emptive scheduling Tasks scheduled locally using pre-emptive FP scheduling

Supply Bound Function [1] I. Shin and I. Lee, "Periodic Resource Model for Compositional Real-Time Guarantees," in Proceedings of the 24th IEEE Real-Time Systems Symposium (RTSS), Cancun, Mexico, 2003, pp. 2-13. • Accounts for non dedicated access to the processor • inverse supply bound function (isbf) • determine the maximum amount of time needed by a specific server to supply some capacity c

Schedulability Analysis for Hierarchical Systems Wrap response time analysis in the inverse supply bound function Restrict the set of tasks to those in the same component

Cache Related Pre-emption Delays (CRPD) Pre-empting task can evict cache blocks belonging to the pre-empted task CRPD are introduced when the pre-empted task has to reload some of those evicted cache blocks after resuming Tasks in other components could evict cache blocks, causing ‘inter-component’ CRPD

Cache Block Categorisation • Evicting Cache Blocks (ECBs) • Loaded into cache and can therefore evict other blocks • Useful Cache Blocks (UCBs) • Reused once they have been loaded into cache before potentially being evicted by the task • If evicted by another task, they may have to be reloaded which introduces CRPD • UCBs are always also ECBs

CRPD in Hierarchical Scheduling Component-level CRPD Task-level CRPD

Integrating CRPD Analysis Component-level CRPD Task-level CRPD determined using the Combined Multiset approach [1] [1] Altmeyer, S., Davis, R.I., and Maiza, C. Improved Cache Related Pre-emption Delay Aware Response Time Analysis for Fixed Priority Pre-emptive Systems. Real-Time Systems, 48, 5 (September 2012), 499-512.

Approach Variation 1 ‘-All’ This approach could be pessimistic if servers do not have equal periods Assume that every time server SG is suspended, all of the other servers run and their tasks evict all the cache blocks that they use

Approach Variation 1 ‘-All’ Assume that every time server SG is suspended, all of the other servers run and their tasks evict all the cache blocks that they use

UCB-ECB-ALL Multiplied by the number of times component G is suspended and resumed during the response time of task τi Multiplied by the cost incurred when reloading a block,the Block Reload Time (BRT) Calculate the union of ECBs of all other components Calculate the union of UCBs of task τiand all tasks that are part of component G that could pre-empt it

Approach Variation 2 ‘-Counted’ Tasks in component Z cannot evict the same cache block multiple times even if component Z runs more than once while component G is suspended Consider each component separately by calculating the number of disruptive executions that server SZ can have on task τiin component G during the response time of task τi

Approach Variation 2 ‘-Counted’ Consider each component separately by calculating the number of disruptive executions that server SZ can have on task τiin component G during the response time of task τi

UCB-ECB-Counted Summed for all other components Calculate the union of UCBs of task τiand all tasks that are part of component G that could pre-empt it, intersected with the ECBs of component Z Multiplied by the number of disruptive executions of component Z during the response time of task τi

Approach Variation 3 ‘-Open’ • Ignore details of other components, assume all blocks are evicted by the other components • Variation of ‘-All’ approaches • The union of ECBs of the other components is assumed to contain all cache blocks • Allows the analysis to be used when no information about the other components is available

Evaluation Methodology • Assign equal server periods to all components • Split tasks equally between components • Default of 24 tasks and 3 components • Determine if the system is schedulable • Perform a binary search to find the minimum server capacity required to schedule each component • As server periods are equal, if the total capacity of all servers is less than 100% then the system is schedulable

Evaluation Accounting for all of the other components at once, or assuming that the cache is flushed, performs the best Considering just the other components, and doing so individually performs the worst

Number of Components There is no difference between the ‘-All’ and ‘-Counted’ variants when there are two components Assuming the cache if flushed every time a component is suspended is not effective with one component

Server Period Minimising the server periods maximises schedulability when component CRPD is not considered In practice, the server period must be carefully selected

Cache Utilisation Once the cache utilisation of the other components is > 1, assuming the cache is flushed each time a component is suspended can be as effective as the more sophisticated approach When the cache utilisation is low, not considering the other components can be overly pessimistic

Conclusions • Presented a number of approaches for bounding CRPD under hierarchical scheduling with a local FP scheduler • Shown that it is important to consider inter-component CRPD • Note that minimising server periods does not maximise schedulability, as is the case when inter-component CRPD is not considered • Must select the server period carefully • If the components fill the cache, simply assuming the cache is flushed each time a component is suspended can be very effective with equal server periods • Allows a bound on CRPD to be calculated without any information about the other components in the system

Thank you for listening Any Questions?

Accounting for Cache Related Pre-emption Delays in Hierarchal Scheduling