Embedded Multicore processing for Mobile Communications Real-time Contracts and Thread Profiling York Jack Whitham

2 Threads and Applications A thread is an execution context. An application is a collection of threads. Not shown: a task (a memory space shared by one or more threads).

3 Thread Utilisation Each thread has an associated utilisation U. utilisation U – the amount of CPU resource required by the thread. C = execution time estimate T = thread period York’s work attempts to ensure that every application receives the CPU resource that it needs. How? Contracts and Servers.

4 What is a contract? A contract specifies the CPU resources needed by an application. 1-1 relationship between contracts and applications. Contracts are generated by the CG tool (made in York) based on the requirements of an application (thread utilisation data).

5 What is a server? A server represents a virtual CPU offering a guaranteed utilisation to a group of threads. Server utilisation = A physical CPU can be partitioned into two or more servers.

6 CG (contract generator) tool The CG tool aims to efficiently partition a system: – Always allocate dedicated CPUs to each application (or component) whenever possible. – Otherwise, try to use as few servers as necessary. CG tool input: – For each thread: Thread ID and Thread Utilisation The CG tool groups threads according to their utilisation: – CG places threads into groups. – Whenever the total utilisation of a group of threads U total satisfies Threshold_L <= U total <= Threshold_H, a dedicated CPU is required. – Otherwise, a server with a utilisation of U total (probably with some margin) will be used. CG tool output: – One contract for each application.

7 Contract Negotiation Negotiation determines which servers should run on each CPU in order to satisfy contracts. Negotiation may fail if insufficient CPU resources are available to schedule the servers. A contract (generated by CG) contains the following information: 1. Number of dedicated CPUs required. 2. Thread allocation to these CPUs. 3. Number of servers required. 4. The utilisation of each server. 5. Thread allocation to each servers.

8 Example of Negotiation

9 CN (contract negotiation) tool The CN tool (developed in York) assigns CPU resources in order to satisfy contracts. CN tool input: – Number of available CPUs (N). – User-specified shortest period of any server (T). CN tool algorithm: – Allocate dedicated CPUs first (must be less than N). – Use First-Fit-Decreasing-Utilisation algorithm to allocate servers (of all contracts) to the remaining CPUs and see whether they are schedulable. CN tool output – for each CPU: – Set of threads (and priorities) to run on this CPU. – Set of servers (and priorities) to run on this CPU. – Server periods (deadline = period) and budgets. – IDs of threads that will run under a specific server (including priorities).

10 Results CPU time is guaranteed to each server. – Note that this is not a hard real-time guarantee for each thread. Synchronisation and communication between threads are not supported in the current version but they will be added soon. Contracts require utilisation data for each thread: To use contracts, L4 and LOBA must support the concept of a server. C = execution time estimate T = thread period

11 Obtaining utilisation data York has extended L4 with a thread profiling tool called “csamon”. The tool dumps live thread execution statistics from L4. We can use it to calculate the utilisation of each thread. We can also use it to visualise what is happening inside the system.

12 csamon We need your help with “csamon”. We have to test it with VAST. We need utilisation data for LTE and other parts of the system. Download “csamon” from York: Instructions on the web. Patches can be applied to L4 snapshots from Dresden.

13 Todo: Server support A server is a group of threads that share an execution time budget. CN gives a budget and period to each server. The budget is smaller than the period. When the execution time budget of a server is exhausted, the threads in that server cannot run until the budget is replenished at the end of the period. In order to use contracts, L4 and LOBA must be aware of servers.

14 Research work from York Time-predictable access to dynamic data from C programs. – As discussed in October - tasks on MPcore/Cortex-A9 are not time- predictable in a hard real-time sense; how could this be improved? – What’s the problem? Data caches Shared memory Heuristic optimisations in each CPU e.g. branch prediction. Replace data cache with data scratchpad/tightly coupled memory? – Creates a problem for dynamic data structures. No problem if all variables are local or global, but what about malloc in C, and new in Java/C++?

15 Research work from York New scratchpad technology is required. – Initial simulator and Microblaze implementations working. – Data cache can be entirely replaced by a time-predictable component which can store dynamic data structures. – Details - – Automatically applied to SPEC and Mibench software with good results in many cases, but some programs need to be modified to make best use of the new technology. – Two conference papers in submission, one technical report published, downloadable software and HDL on website. Future work: more analysis and development required!

16 Summary York has developed a contracts model and three tools (CG, CN, csamon). York has done some research into time-predictable memory. York needs the utilisation data for the threads in the finished system. York must work with Dresden to implement support for servers in L4 and LOBA. More information about contracts and servers: – See emuco-wp2 mailing list archive for 18 th June 2009.

17 Prof. Dr. Ing. Attila Bilgic Ruhr-Universität Bochum Institute for Integrated Systems Universitätsstrasse 150 D Bochum GERMANY ICT-eMuCo is a European project supported under the Seventh Framework Programme (7FP) for research and technological development Project Coordination: Jack Whitham / Yang Chang / Neil Audsley