Yes. With HRT you have timing measures with a higher resolution than
using normal timers. This means that everything in the system runs more
precisely, and latencies are reduced.
However, "how" it runs, depends on the scheduling algorithm, which is
the part of the kernel that at any instant chooses which task must be
executed. Our scheduling class introduces the chance of ordering tasks
execution in a further manner, that is according to the Earliest
Deadline First (EDF) algorithm. Therefore, after the patch is applied, a
new scheduling policy is available for scheduling tasks. Consider that
old policies (sched_fair and sched_rt) still remain, and you are not
forced to use EDF ordering. This way, if you don't use EDF tasks, the
system still behaves as without our patch.
Let's take a step back. The problem in real-time scheduling is to find
an order of scheduling tasks so that each of them meets its deadlines.
This way, you get determinism and predictability (i.e., you can trust
that your tasks will be executed at the "right" instant of time).
Several scheduling algorithms exist to generate different orders of
execution that ensure this property.
In particular, several differences exist between fixed priority and
dynamic priority algorithms (like SCHED_EDF). In my opinion, the most
relevant is the following one.
Suppose you have a single processor and a set composed by periodic
real-time tasks, each one characterized by an amount of execution time
("budget") that must be executed every "period". This way, the deadline
for each task is equal to the end of its current period.
The sum of (budget/period) of all tasks is usually called "bandwidth".
Using fixed priority schedulers, you need a quite complicated equation
to understand if it is possible to guarantee the deadlines of every
task. This equation must be re-computed each time you change a budget or
period of some task.
Even worse, depending on the task set, it may happen that the bandwidth
must be lower than 100% (sometimes as low as 69%), otherwise you cannot
be sure that all tasks will meet their deadline (they might, but you
cannot trust).
With EDF, instead, the test is much easier: if the bandwidth is less
than 100%, then you are sure that the deadlines will be met. In other
words, you can fully exploit processor bandwidth up to 100% being sure
that timing constraints of EDF tasks will be guaranteed.
Well, ACTORS is an example of an industrial application which needs an
EDF scheduler on Linux, isn't it ?
But I've also seen a couple of multimedia applications which needed an
EDF scheduler to meet deadlines of periodic tasks and, at the same time,
exploit CPU utilization up to 100%.
Regards,
Claudio
--
