Implementation and study of the BandWidth Inheritance protocol in the Linux kernel

02/10/2007, Dario Faggioli Implementation and study of the BandWidth Inheritance protocol in the Linux kernel

Dario Faggioli, October 2 2007

Corso di Laurea Specialistica inIngegneria Informatica

Tesi di Laurea Specialistica

Implementation and studyof the BandWidth Inheritance protocol

in the Linux kernel

Facoltà di IngegneriaFacoltà di IngegneriaUniversità di PisaUniversità di Pisa

Relatori:Prof. Paolo AncilottiProf. Giuseppe Lipari

Candidato:Dario Faggioli


Implementation and study of theBandWidth Inheritance protocol in the Linux kernel

Real-time systems

− Definitions

− Real-time scheduling and resource sharing

− Server based scheduling and resource sharing

− Soft real-time systems, QoS and Resource Reservation

The AquoSA Framework

− Framework objectives and design goals

− AquoSA Framework architecture and usage

BWI implementation inside AquoSA

− Design and goals

− Specific contribution

− Implementation characteristics

BWI implementation verification

BWI experimental simulations results

BWI implementation overhead evaluation



Real-time systems

− Definitions















Real-time systemsDefinitions

Some definitions of a real-time system

− A set of activities with timing requirements

− A system interacting with the external environment which directly imposes its rigid requirements on timing behaviour, usually as constraints on response and/or worst case computation time

− A system the correctness of which depends both on the accuracy of the computation results as well as on the time at which those results are produced and presented as output

Differences with “traditional” systems

− “traditional” systems aims at achieving maximum possible throughput, fairness and complete exploitation of available resources

− real-time systems aims at achieving predictability and determinism



Hard real-time systems

An hard real-time system completely fail if its timing constraints are not honored, even only one single time

An hard real-time system typically handles critical activities

− flight control systems

− defense systems

− nuclear power plants control systems

− ...

An hard real-time system causes, if it fails, catastrophic consequences



Soft real-time systems

A soft real-time system can tolerate some miss to happen considering such an event only a temporary failure

A soft real-time systems typically are are non critical systems

− audio/video players

− multimedia applications

− (multimedia) streaming applications

− VR or video games and entertainment systems

− ...

A soft real-time system produces, if occasional constraints violations occur, no cataclysmic effects

A soft real-time system produces, if occasional constraints violations occur, a degradation of the Quality of Service perceived by the user



Real-time theory

the scientific discipline that provides solutions to the problem of being able to design systems with full predictable timing behavior, also showing (mathematically) evidences that they meets all their timing requirements

Real-time tasks

An “activity” to be performed inside a real-time system is usually called a task and is characterized by some parameters

Utilisation factor (for each task)

periodic task ti, job j and j+1c

i,jai,j

fi, j

di,j

ci,j+1

ai,j+1

fi, j+1

di,j+1D

i,j=T

i

ci,j

ai,j

fi, j

di,j

non periodic task ti, job j and j+1c

i,j+1a

i,j+1 fi, j+1

di,j+1

Ti,j,j+1

Di

U i=c i

T i

=max j {c i, j

}min j{T i, j, j+1

}


Real-time systemsReal-time scheduling and resource sharing

Real-time scheduling

Trying to find an order of execution of all the jobs of all the tasks in the system so that any of them meets their deadlines

Real-time scheduling algorithms

− Rate Monotonic (RM)tasks are executed in priority order, with the highest priority task being the one with the shorter period

− Earliest Deadline First (EDF)tasks are executed in priority order, with the highest priority task being the one with the earliest (absolute) deadline

U=Ui=

ci

Ti

<n21n−1

U=Ui=

ci

Ti

<1



Sharing resources and synchronization between tasks

In complex systems tasks may need to compete or cooperate by means of shared resources collocated in shared memory areas and protected by mutex semaphores providing mutual exclusive access

Priority inversion

The use of classical semaphores is prone to the well known priority inversion problem

an high priority task is blocked by a low priority one for an unbounded amount of time due to the interference of some other task, with medium priority between the two

Caused problem also during Mars Pathfinder mission !!

Priority Inversion avoidance:

− Non Preemptive Protocol (NPP)

− Highest Lock Priority Protocol(HLPP)

− Priority Inheritance Protocol (PIP)

− Priority Ceiling Protocol (PCP)

− Stack Resource Policy (SRP)R R R

R

WR

WR

SR

SR

Priority inversion !

T1

T2

T3



PIP rules

The PIP achieve its objectives through two simple rules

− when a task TH is blocked accessing a critical section whose mutex is already

locked by TL (and if T

H has higher priority than T

L) then T

L inherits the priority of T

H

− when TL releases the mutex it is returned the priority it had before acquiring it

PIP Example

R R R

R

WR

WR

SR

SR

Priority inversion !

T1

T2

T3

T1

T2

T3

R R

R

WR

WR

SR

SR

Priority inheritance


Real-time systemsServer based scheduling and resource sharing

Server based scheduling

A server Si is an entity characterized three parameters

− Qi

the budget or capacity

− Pi

the period

− the server bandwidth

Servers are the actual scheduling entities

A server serves one or more tasks

− hard or soft

− periodic, sporadic or aperiodic

− typically sporadic soft real-time tasks aperiodic non real-time tasks

When a server is scheduled its tasks are given a chance to run

CPU

EDFready queue

T1

T2

T3

S1

S2

S3

T4

T5

T6

Hardtasks

Softtasks

U i=Q i

P i



Server based scheduling

While a server executes its actual budget is decreased

When a server's budget reaches zero it is periodically recharged

It is usually possible to ensure a task it will run at least for Qi units of time

during each Pi period (depending on the server algorithm)

Some server algorithms

− Polling Server (PS),

− Deferrable Server (DS)

− Sporadic Server (SS)

− Total Bandwidth Server (TBS)

− Constant Bandwidth Server (CBS)



Constant Bandwidth Server (CBS) based scheduling

Each CBS server is also characterized by

− qi (q

i(t)) the current server budget at time instant t

− di (d

i(t)) the current server deadline at time instant t

The CBS algorithm works as follows:

− CBS initialization: for each server Si, q

i=Q

i , d

i=0

− CBS rule A: when a new job of Ti, within S

i, arrives the server

checks if true nothing has to be done

if false qi=Q

i, d

i=d

i+P

i

− CBS rule B: when a Si executes for Dt time units q

i=q

i-Dt

− CBS rule C: when qi=0 q

i=Q

i , d

i=d

i+P

i

CBS fundamental property

The contribution of the tasks served by Si to U is guaranteed to be not greater than U

i

qi(di−ai )U i



Some CBS properties

The basic ideas behind the algorithm are

− when a request for a task execution arrives it is assigned a deadline calculated taking into account its server's bandwidth

− when a task tries to execute more than what it is expected its deadline is postponed, so that it is slowed down

The algorithm works

− without requiring the WCET to be a-priori known

− without requiring the period or MIT to be a-priori known

The algorithm provides the Bandwidth Isolation Property (BIP)

− the fraction of the CPU bandwidth of a CBS server is U=Q/P independently from the computation time of the served tasks independently from the arrival time pattern of the served tasks

− the fraction of the CPU bandwidth the server can exploit is U=Q/P independently from the computation time of other tasks in the system independently from the arrival time pattern of other tasks in the system



Sharing Resources with CBS

Within CBS algorithm no resource sharing is allowed

if a task blocks itself we are no longer sure the executing serveris the one with the earliest deadline

PIP can not be “simply” applied here

− what happens if SL exhausts its budget

after it inherited SH's priority (deadline)?

− which deadline has to be postponedand whose budget recharged ?

This leads to

− priority inversions !

− BIP breakout !

S1=(4, 16)

S2=(4, 24)

S3=(9, 36)

S4=(1, 4)

WR

Priorityinversion !

R R

WR

R

SR

R

SR

deadline miss !

0 2 4 6 8 10 12 14 16 18



BandWidth Inheritance protocol

Only adds two rules to the CBS algorithm

− CBS rule D: when Ti blocks while accessing R owned by T

j, then T

j is added to the

list of tasks served by the server Si.

If even Tj is blocked the chain of blocked tasks is followed and all the encountered

tasks are added until one that is not blocked is found

− CBS rule E: when Tj releases R and T

i is resumed the server S

i discards T

j from its

list and all the servers that has previously added Tj replace it with T

i

S1=(2, 6)

S2=(2, 6)

S3=(6, 18)

R

WR

0 2 4 6 8 10 12 14 16 18 20

R R

WR

SR

SR

R

deadline postponements



BandWidth Inheritance protocol

Natural extension of Priority Inheritance Protocol toward the CBS

− bandwidth isolation property

− bounded blocking delay and no priority inversions

Real inheritance protocol

when a task blocks himself on a mutex the lock-owner inherits its whole server

Addresses the open issues of PIP and CBS

− what happens if SL exhausts its budget

after it inherited SH's priority (deadline)?

A task is able of being scheduled withthe earliest deadline between all theeligible servers it has been added to

− which deadline has to be postponedand whose budget recharged ?They are the ones of the serverin which the task is executing

S1=(2, 6)

S2=(2, 6)

S3=(6, 18)

R

WR

0 2 4 6 8 10 12 14 16 18 20

R R

WR

SR

SR

R

deadline postponements



BandWidth Inheritance protocol and isolation

Interacting tasks

− Ti and T

j have to be considered interacting tasks if

Ti and T

j share a resource R

a chain of tasks T1, T

2, T

3, ... T

n exists such that T

i=T

1 and T

j=T

n and,

for each k=1, 2, 3, ..., n, Tk and T

k-1 share a resource R

k

BWI is able to provide isolation among non-interacting task

It is impossible to provide isolation among interacting tasks !!

S1=(4, 16)

S2=(4, 24)

S3=(9, 36)

S4=(1, 4)

R

R

R

0 2 4 6 8 10 12 14 16 18

WR

WR

SR

R

SR

20 22 24 26 28 30 32 34

S1=(4, 16)

S2=(4, 24)

S3=(9, 36)

S4=(1, 4)

WR

R R

WR

R

SR

R

SR

deadline miss !

0 2 4 6 8 10 12 14 16 18


Real-time systemsSoft real-time systems, QoS and Resource Reservation

Building a soft real-time system

Soft real-time applications are characterized by more relaxed constraints

− some deadline misses can be tolerated up to a certain degree

− control on the system performance and resource usage is still required

The main goal dealing with soft real-time applications is not to prevent all the deadline to be missed, beside to keep this phenomenon under control

What it is desirable in a soft real-time system is

− maximize the utilization of the system resources (not too pessimistic assumptions)

− remove any need of precise a-priori knowledge about the applications

− achieve graceful degradation of the performances

− provide isolation to each application, so that an overrun in any of them do not influence the normal execution of the others

An hard real-time approach would mean an unacceptable waste of resource and it is definitely not appropriate



Soft real-time systems and Quality of Service (QoS)

The user's satisfaction is a decreasing function of

− the number of the timing constraints violations

− the severity (e.g. mean tardiness) of the constraints violations

An optimal measure of the provided QoS could right be theratio of deadline miss over a given time interval

the lower the deadline miss ratio, the better the QoS

The main challenges with soft real-time systems are

− increasing efficiency in resource usage

− keep the overall cost of the system low

− removing any assumptions on the exact knowledge of execution times

− ensure some guarantees on the performances of the system

not an absolute “yes-or-no” as by the notion of QoS



Resource Reservation

A very effective approach to soft real-time systems

− temporal protected (isolated) access to shared system's resources (e.g. CPU) each application is reserved a fraction of a system's resource utilisation time its ability to meet the timing constraints is not influenced by any other application

Each soft real-time task is assigned a fraction of the CPU time (bandwidth)and is scheduled in such a way it will never demand more that its bandwidth

If the task requires to execute more than its bandwidth it is slowed down

− overruns occurring on Ti will only affect and delay the execution of T

i itself

− no one is able to steal any crumb of bandwidth reserved to the other tasks

No reciprocal tasks interference allowed

− a task executes on a dedicated virtual processor running at a fraction of the speed of the real one equal to its reserved bandwidth

− the problem of schedulability analysis reduces to the estimation of the computation time of a task, without considering the rest of the system, in order to assign it the proper bandwidth



Resource Reservation and CBS

We can effectively realize the RR utilising the CBS algorithm

The BIP provided by the CBS is the perfect vehicle for providing temporal isolation

Resource Reservation and BWI

We can also utilise the BWI-modified CBS algorithm

− the arrival times of the tasks need no to be known

− the execution times of the tasks need not to be know

− the mutual exclusive resources a task will access is not to be known

− the duration of each critical section is not to be known



Real-time systems

− Definition





− Objectives and design goals

− Architecture and usage









The AQuoSA FrameworkObjectives and design goals

AquoSA Framework

Adaptive Quality of Service Architecture (AquoSA)

− Free Software project developed at the Real-Time Systems Laboratory(RETIS Lab, Scuola Superiore Sant'Anna, Pisa)

− aims at providing Quality of Service management on a GNU/Linux system



AquoSA Framework

What GNU/Linux offers to soft real-time applications

− a low-latency and fully preemptable kernel

− high-resolution timing support

− (almost) all the real-time capabilities defined in the POSIX real-time extensions

What GNU/Linux lacks

− a predictable scheduler with timing and/or QoS guarantees

− a temporal protection and isolation mechanism so that an application can access the soft real-time scheduler

but not exploit it to starve all the other applications in the system an application can have the guarantees it has been provided respected

in all system's load conditions and independently on misbehaviour of any other one

AQuoSA wants to fill this gap

provides a standard GNU/Linux system with all it's needed to offer time-sensitive applications a guaranteed behaviour and the temporal protection property



Some AQuoSA design goals

AQuoSA is developed trying to achieve the following key goals

− Portability:layered structure where kernel dependent code is confined in the lowermost level

− Backward compatibility: no change to the API and ABI of a standard Linux kernel

− Flexibility:easy to introduce new scheduling algorithms and policies

− Efficiency:overhead introduced reduced to minimal measure

− Security:control on the assigned bandwidth by the system administrator in order to prevent erroneous or voluntary denial of services to happen


The AQuoSA FrameworkArchitecture and usage

AquoSA architecture

Resource Reservation (RR) layer

− provides the system with the EDF scheduler the RR mechanism (IRIS) the reservation supervisor

− is responsible for all that regards the reservations creation the reservations deletion the enforcement of the timing behaviour

of the reserved tasks

QoS Manager layer

a set of predictor and controllers forfeedback based scheduling

QoS Managerlayer

QoS ManagedApplication

QoS ReservedApplication

GNU/LinuxApplication

QoS Resource Reservationlayer

GNU/Linux system



AQuoSA architecture and components:

The architecture is realized by the following main components:

− Generic Scheduler Patch (GSP): a small patch to the Linux kernel extending the Linux scheduler functionalities

− Kernel Abstraction Layer (KAL):a set of functions and macros abstracting all we need from the kernel

− QoS Reservation component: resource reservation kernel module (rresmod) which implements EDF and the RR

scheduling algorithms resource reservation supervisor kernel module (qresmod) which grants no system

overload to occur resource reservation and supervisor libraries (qreslib and qsuplib) which provides the

application level APIs

− QoS Manager component: QoS manager loadable kernel module (qmgrmod) QoS manager library (qmgrlib)



AQuoSA architecture and components:

● The architecture is realized by the following main components:

● Generic Scheduler Patch (GSP): a small patch to the Linux kernel extending the Linux scheduler functionalities

● Kernel Abstraction Layer (KAL):a set of functions and macros abstracting all we need from the kernel

● QoS Reservation component:● resource reservation kernel module (rresmod) which implements EDF and the RR scheduling

algorithms● resource reservation supervisor kernel module (qresmod) which grants no system overload to

occur● resource reservation and supervisor libraries (qreslib and qsuplib) which provides the

application level APIs

● QoS Manager component:● QoS manager loadable kernel module (qmgrmod)● QoS manager library (qmgrlib)




Linux kernel

GSP

qsuplib qreslibqmgrlib glibc

QoSReservationcomponent

QoSManager

componentqmgrmod

qresmod

rresmodEDFScheduler

Kernel Abstraction Layerkernel-space

user-space



AquoSA usage

QoS resource reservation library

− from within application code

From the Command Line Interface

qres and qres-wrap utilitieswith all the sameAPI functionalities

From the Graphical User Interface

AQuoSA Monitor much moreuser friendly interface



Real-time systems

− Definition









− Specific contributions






BWI implementation inside AquoSADesign and goals

BWI implementation

Before this work AQuoSA offered no support for critical sections access

when a task blocks it is assumed an instance is finished !!

We started this work with the following specifications

− to realize a full and functional implementation of the BWI protocol inside AQuoSA

− to make it possible to enable or disable the protocol at compile time

− to make it be possible to use or not use the protocol at run time(for each specific mutex and critical section)

− to alter as little as possible impact as possible the AQuoSA code and architecture

− to add as little as possible overhead both in space (memory occupation)and in execution time


BWI implementation inside AquoSASpecific contributions

Some contributions

Lightweight deadlock check

Since each time a task Ti blocks we walk through the whole chain of blocked tasks

starting from it, it is sufficient we to encounter Ti again to identify a deadlock

situation with zero overhead

Adding only one task

− As a performance optimization each time Ti blocks and we follow the chain of

blocked tasks till a running one, we can add only such an able to run task

− This means, since each task Ti can, at each time instant t, be blocked at most by

only one other task Tj, the following property always holds:

BWI one blocked task property:at each time instant t each task T

i is being blocked by at most one task T

j,

and so only Tj is executing inside its server S

i due to T

i itself



Some contributions

Nested critical section handling enhancement

A slight but effective modification of the algorithm

− the CBS rule D does not account for the case a task blocks when it already has been added to some servers(i.e. while holding at least a mutex with at least one another blocked task)

− we have modified it into the CBS rule D' (and implemented the latter)

CBS rule D': when Ti blocks while accessing R owned by T

j, then T

j is added to all the

list of tasks of all the servers which also serves Ti.

If even Tj is blocked the chain of blocked task is followed and all the encountered

tasks are added to all these servers' list, until one that is not blocked is found



Some contributions






j, then T





CBS rule D: when Ti blocks while accessing R owned by T

j,

then Tj is added to the list of tasks served by the server S

i.

If even Tj is blocked the chain of blocked tasks is followed

and all the encountered tasks are added until onethat is not blocked is found



Some contributions






j, then T





CBS rule D: when Ti blocks while accessing R owned by T

j,

then Tj is added to the list of tasks served by the server S

i.

If even Tj is blocked the chain of blocked tasks is followed

and all the encountered tasks are added until onethat is not blocked is found


BWI implementations inside AquoSAImplementation characteristics

Description of the implementation

Non intrusive approach

Do not modify the core features of AquoSA, that is the scheduler and scheduler related functions the RR enforcing mechanisms the servers handling (list of tasks, dispatching, etc.) mechanisms

BWI added functions only called in very few situations

− when a task is attached or detached to/from a server

− when a task blocks or unblocks on/from a mutex

Quantitative data

− only 4 core functions, 3 utility ones and some KAL macro added

− only 2 files have been newly created

− only 6 files lightly modified modified

− totally 260 lines of code added

− totally 6 lines of code modified





− Do not modify the core features of AquoSA, that is the scheduler and scheduler related functions the RR enforcing mechanisms the servers handling (list of tasks, dispatching, etc.) mechanisms




Quantitative data









Linux kernel

GSP

qsuplib qreslibqmgrlib glibc

QoSReservationcomponent

QoSManager

componentqmgrmod

qresmod

rresmodEDFScheduler

Kernel Abstraction Layerkernel-space

user-space

rres_bwi

kal_bwi





− Do not modify the core features of AquoSA, that is the scheduler and scheduler related functions the RR enforcing mechanisms the servers handling (list of tasks, dispatching, etc.) mechanisms




Quantitative data






T1

T2

task_struct...private_data...

task_listtaskotherssrvbwi_blocked_onbwi_wait_taskbwi_orig_srvbwi_entries

server_t

tasks


server_t

tasks


blocked on

...

...

...

...

task_struct...private_data...

S1

S1



Real-time systems

− Definition
















Verification

Static analysis

− during the whole process of code development

− assertions placed throughout the code to ensure consistency in some critical points

Dynamic analysis (testing)

− a lot of test programs have been run checking the output they produces is exactly what we could have expected none of the assertions added during static analysis is violated

Stress tests

− a lot of test programs have been run caring of all the code paths are covered all the identified abnormal situations are correctly handled

− all the test programs have been run in different system load conditions

(Inverse) integration tests

− all test programs have been run whit BWI not being used by them

− all test programs have been run with our code compiled out



Verification

Static analysis

− during the whole process of code development

− assertions placed throughout the code to ensure consistency in some critical points

Dynamic analysis (testing)

− a lot of test programs have been run checking the output they produces is exactly what we could have expected none of the assertions added during static analysis is violated

Stress tests

− a lot of test programs have been run caring of all the code paths are covered all the identified abnormal situations are correctly handled

− all the test programs have been run in different system load conditions

(Inverse) integration tests

− all test programs have been run whit BWI not being used by them

− all test programs have been run with our code compiled out

E. W. Dijkstra:<<testing can only reveal the existence of programming errors, not prove their absence>>



Real-time systems

− Definition















BWI experimental results

Experimental simulations

We build and ran some simulations in order to

− prove BWI is an effective solution for handling critical sections and resource sharing in a real and running RR based soft real-time system

− point out some if its fundamental properties and benefits it introduces

List of the simulations we ran

− BWI enforcement bwi_test_bwi_1 bwi_test_bwi_2

− Priority inversion control bwi_test_inversion

− Compliance with the BIP bwi_test_isolation

− Full bandwidth exploitation bwi_test_bandwidth_1 bwi_test_bandwidth_2 bwi_test_bandwidth_3



Experimental results

bwi_test_bwi_1

− BWI not used

− BWI used

Thread A's tardiness is significantly decreased

407.80196 msec instead of 1905.8146 msec after 10 runs

Th. A=(10, 10, 100)

0

W0

0

deadline misses !

20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340

W0

0 0

S0

0

S0

0 0 0deadline hit

0

W0

S0

S0W

0

360 380 400 420 440 460 480 500 520

0

W0

Th. B=(30, 10, 100)

00

0

W0

W0

0

S0

0

S0

0

W0S

0

0

W0

0

0

S0

0

W0S

0

0

W0S

0

deadline hit

deadline misses !

Th. B=(10, 10, 100)

Th. A=(10, 10, 100)




bwi_test_inversion

− BWI not used

− BWI used

Deterministicbehaviour achieved

0

W0

0

W0

0 20 40 60 80 100 120

0

0

S0

S0

Th. B=(40, 320)

Th. A=(30, 100)

Th. C=(40, 480)0

W0

0

W0

0 20 40 60 80 100 120 140

0

0

S0

S0

Th. B=(60, 320)

Th. A=(30, 100)

Th. C=(40, 480)

0

W0

0

W0

0 20 40 60 80 100 120 140

0

S0

S0

Th. B=(60, 320)

Th. A=(30, 100)

Th. C=(40, 480)0

W0

0

W0

0 20 40 60 80 100 120 140

0

S0

S0

Th. B=(40, 320)

Th. A=(30, 100)

Th. C=(40, 480)




bwi_test_isolation

1

0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300

0

W0

W1

W0

1 1

W1

1

S1

1

0

S0

0

S0

320 340

S1

Th. B=(100, 380)

Th. A=(40, 140)

Th. C=(20, 600)

Th. D=(40, 150)

Th. E=(40, 500)

1

0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300

0

W0

W1

W0

1 1

0 0

S0

320 340

S1

S0

0

W1

S1

1

Th. B=(100, 380)

Th. A=(40, 140)

Th. C=(20, 600)

Th. D=(40, 150)

Th. E=(40, 500)




bwi_test_isolation

1

0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300

0

W0

W1

W0

1

1

0 0

S0

320 340

S1

S0

0

W1

1

S1

Th. B=(20, 300)

Th. A=(40, 140)

Th. C=(20, 600)

Th. D=(40, 150)

Th. E=(80, 500)

1

0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300

0

W0

W1

W0

1 1

W1

1

S1

1

0

S0

0

S0

320 340

S1

Th. B=(20, 300)

Th. A=(40, 140)

Th. C=(20, 600)

Th. D=(40, 150)

Th. E=(80, 500)




bwi_test_bandwidth_1

(2 thread, 1 mutex)

Full Bandwidth exploitation

Boosted finishing time





(3 thread, 2 mutex)







(8 thread, 5 mutex)





Real-time systems

− Definition
















Overhead evaluation

Space/Memory

look at the size of difference between the two cases BWI is compiled or not of the rresmod.ko file, i.e. the loadable kernel module its .text ELF section, i.e. the code actually loaded and executed

BWI not enabled BWI enabled Difference Difference %module size (byte) 563055 609796 46741 8.3.text length (byte) 31852 42196 10344 32.48



Overhead evaluation

Time/Execution

− profile the functions in which the call to our 4 core routines have been inserted when BWI is compiled but not used when BWI is compiled and used

− look at the differences between mean and maximum execution time obtained values and the case BWI is not compiled in the framework

BWI compiled out BWI not used Difference BWI used Differences7 8 1 7 06 6 0 7 19 9 0 12 36 6 0 6 0

BWI compiled out BWI not used Difference BWI used Differences4.840 5.080 0.240 5.000 0.1603.467 3.477 0.010 3.636 0.1695.721 5.773 0.052 5.837 0.1164.720 4.920 0.200 4.960 0.240

Max. Execution Time (usec)

rres_attach_task_noschedrres_block_hookrres_unblock_hookrres_detach_task_nosched

Mean Execution Time (usec)

rres_attach_task_noschedrres_block_hookrres_unblock_hookrres_detach_task_nosched



Overhead evaluation

Context Switches

− investigate how BWI behaves with respect to context switches does it introduce any additional context switch ? does it reduce the number of context switch ?

− count the context switches and evaluate the differences between the cases BWI is not used BWI is used

bwi_test_bwi_1 (periodic tasks)

bwi_test_bandwidth_2 (greedy tasks)

BWI not used BWI used DifferenceThread A 26 24 -2Thread B 34 34 0

BWI not used BWI used DifferenceThread A 607 343 -264Thread B 414 316 -98Thread C 405 405 0

Technology

Implementation and study of the BandWidth Inheritance protocol in the Linux kernel