2 The aim of this research is to provide higher energy efficiency to platforms running General Purpose Operating Systems (GPOSs). Hard Real-Time Operating Systems
1 Modified the Figure to have a clearer explanation
2 Added this new subsection
(RTOSs), as explained in Section 2.3 which exhibit deterministic timing behaviour and have hard deadlines, are out of the scope of this work. The RTMs is then designed in a cross-layered GPOS environment, analysing the non-deterministic timing nature of these OSs. Examples of this environment are Linux, Windows and Android. The aim of this work is to relate GPOSs to have a Soft Real-Time (RT) behaviour. In GPOSs the applications are not performance constrained explicitly as the ones in an RTOS, therefore no effort is done by the OS scheduler to achieve a specific performance for the applications.
Applications running in an RTOS provide a performance requirement in the form of deadlines for the workloads to be executed, therefore allowing the RTM to obtain energy savings by reducing the performance of the workload whilst achieving the deadline. The RTM proposed is aimed to sit in the GPOS spectrum but to provide an RTOS-like behaviour. This means that the target applications must have a non-necessarily explicit performance requirement for it to be the optimisation target. A non-necessarily explicit performance requirement means that the scheduler is not notified of the requirement.
The timing requirement can be seen as the maximum time allowed for the workload to be finished. The unit of workload is then defined as a frame. Therefore, the performance requirement is then defined as the number of workload frames that need to be executed per second, or frames-per-second.
The other major component of an Real-Time System (RTS) is the Worst - Case Execu-tion Time (WCET) which allows the scheduler to decide how to run the task. In a Hard RTOS the WCET must be provided, whereas in GPOSs this is not given. This means that in a GPOS the WCET of the workload to be processed needs to be calculated. The control algorithm is then responsible for this calculation, given that the application can provide annotations to help this calculation be more precise.
The environment for the RTM is then a system in which the workload for an application is divided in frames, and this application has an implicit requirement for the frames to be executed in a specific time, defined as a deadline. These frames can be of different workload sizes i.e. different amounts of CPU Cycles per frame. An example of an application working in this environment is video decoding. In video decoding, the video frames represent the workload. The implicit performance requirement is the frames-per-second (fps) at which the video must run, which are usually contained in the video file itself. The deadline can be calculated as the reciprocal of fps i.e. deadline = f ps1 , as the time allowed for each frame. Also, in this environment resources are limited, including memory. It is assumed that frames are processed at the fps speed i.e. if the frame is finished processing before the deadline, the system is idle until the deadline is reached, when a new frame is brought to be processed. Therefore, idle time cannot be accumulated. The reason behind it is that in the systems targeted there is not enough memory to use as a processing buffer, so only one frame can be processed and buffered at the time.
In this environment, the power management knob available is DVFS, so no PG is taken under consideration as part of the RTM. The race-to-idle[32] approach, in which the strategy is to process the workload as fast as possible and reduce energy consumption during the idle time cannot be applied to this environment.
The cross-layer RTM allows applications to send their requirements (or constraints) to it, which then adjusts its behaviour to achieve those constraints. The constraints analysed in this research are time based, meaning that the RTM must achieve the highest energy savings whilst providing a performance measured in units per second. As the RTM works in a non-deterministic timing environment, it is impossible to ensure Hard RT behaviour, as some deadlines could be missed. The objective is then to achieve Soft RT performance. The main difference between Hard and Soft RT performance is the criticality of not achieving the desired performance when executing the tasks. Soft RT is addressed then, because the task workload is not known a priori. Therefore, without offline profiling of the tasks, the task completion time cannot be known before execution.
The RTM must then attempt to finish the workloads before their deadlines by collecting information at run time, but some may be missed.
Efficient RTMs need requirements in order to have a target to aim for, whether it is to reduce energy consumption, control temperature or provide an amount of performance.
The goal of this work is to provide energy savings whilst achieving Soft RT performance on GPOSs. Soft RT behaviour means completing tasks before reaching their given deadlines, and where missing a deadline is not critical but seen as a performance penalty.
These performance penalties (or lack thereof) have an impact in user experience.
The intention is then to target applications that have an implicit minimum performance requirement. It is implicit because the requirement is not given to the OS and therefore is not considered when scheduling the application. A distinction is done into general purpose applications and Soft RT applications. The former do not have implicit require-ments, so lower performance of these applications does not have a significant impact on user experience, and include text processors, email clients, etc. Soft RT applications have an implicit constraint, whether this is frame rate or throughput (bits per second).
Examples include video processing, rendering, video games, music players, video chat, etc. Watching a video with a lower frame rate than intended can have a negative impact on user experience.
For the RTM to provide Soft RT behaviour, the implicit performance requirements need to be passed to it. These performance requirements are also called annotations, so the application requires extra code to include annotations for it. The RTM needs these implicit requirements and annotations to become explicit to have them as the performance targets.
3.1.1.1 Application adaptation for use with RTM
3 The RTM requires the target applications to provide annotations to it in order to have an optimisation target, as well as to provide information regarding the structure of the application. The former represents the performance requirement in fps. The latter means that the RTM needs to be notified when a new frame of the application is to be executed. The application then requires to be divided into frames. In order to improve energy optimisation even further, the new frame notification should include a type in order to classify frames. This is further explained in Section 3.2.
For the sake of example a video decoder is presented as the target application. The video decoder opens a video file, which contains the fps embedded in the video header.
The application code needs to be modified to send the fps requirement to the RTM as soon as it has been read from the file. The RTM now has its optimisation target. The video decoder starts playing the video, decoding each frame to be displayed. The video decoder code needs to be modified to send the frame start notification to the RTM as soon as it is reached in the application. The RTM notification from the application includes the frame type. After all frames have been decoded, the application finishes execution. It sends a notification to the RTM of the end of the application.
In order to simplify the adaptation of the application code to include the annotations, an Application Programming Interface (API) was designed. This API consists of C func-tions that are inserted inside the code at design-time. Section 4.5 provides a description of the implementation of the API framework.