[LITMUS^RT] Maximum Tasks limit handled by scheduler (GSN-EDF)?

[Glenn Elliott]

On May 27, 2014, at 6:05 PM, Sanjib Das <cnt.sanjib at googlemail.com> wrote:

> Dear All,
> 
> Is there anyone can help me to calculate the maximum number of  tasks generated by https://github.com/LITMUS-RT/experiment-scripts which will not stall the CPUs or SOFT/HARD CPU lock occurrence or feather trace write will not be missed for example GSN-EDF scheduling algorithm.
> 
> Thanks in Advance
> Sanjib

The experiment-scripts are not good at generating schedulable task sets.  That is, it does not check the schedulability of the task sets it generates.  gen_exps.py allows you to place a cap on the number of tasks in a task set, but that does not guarantee schedulability, since schedulability is also determined by per-task utilization.  That is controlled by the period and utilization generation parameters.  Controlling all of these parameters is described in the readme: https://github.com/LITMUS-RT/experiment-scripts#gen_expspy  (also, when in doubt, just run “gen_exps.py --help”).

I’d like to integrate experiment-scripts with schedcat’s schedulability test framework (https://github.com/brandenburg/schedcat).  This would allow us to test schedulability (with or without system overheads included).  I haven’t had the time to explore this yet (it would probably be at least a week’s effort to do it right).

In the meantime, you’re just going to have to hack the generation scripts yourself.  Most of your work will be limited to gen/generator.py and gen/edf_generators.py.

Here’s where experiment-scripts invokes schedcat’s task set generator: https://github.com/LITMUS-RT/experiment-scripts/blob/master/gen/generator.py#L119

Observe that there are two control parameters: the maximum number of task (max_tasks) and max_util (maximum task set utilization).  Observe that experiment-scripts does not set max_util by default.  You’ll have to edit the call of _create_taskset() to provide a cap (the calls are in gen/edf_generators.py).

-Glenn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20140527/bcfa133a/attachment.html>