[LITMUS^RT] Budget enforcement - EDF-WM

Björn Brandenburg bbb at mpi-sws.org
Mon Aug 6 15:26:24 CEST 2012


On Aug 1, 2012, at 5:39 PM, Felipe Cerqueira wrote:
> I'd like to know what you think about making
> budget_remaining()/budget_exhausted() overrideable by the sched
> plugin.
> The timers are set after each schedule(), so by letting these budget
> functions be plugin-dependent, we could update the budget in execution
> time.
> Would it be useful for future algorithms? Or for porting the
> semi-partitioned plugins to the current version?
> What about the overheads after implementing the callbacks?
> 
> There are two other possible solutions for EDF-WM:
> 1) Keep BUDGET_ENFORCEMENT off, and implement all the timer functions
> inside the plugin (like it used to be in the past, so I'd get the code
> from the previous patches).
> 2) Keep BUDGET_ENFORCEMENT on, and change task_params.exec_time to
> trick the scheduler.

The main idea of the current enforcement solution was to make it plugin-independent in the common case. As far as I know it works with all currently "shipping" plugins, which I think is quite nice. I would rather avoid the complexity of another callback.

A semi-partitioned scheduler has to enforce budgets of migrating tasks anyway, so the budget policy parameter is meaningless for such tasks. Therefore, I think it would be easiest to follow approaches 1) or 2).

A cleaner variant of 2) would be to have two new fields 'slice_exec_time' and 'slice_budget'. The enforcement timer code would only use these two fields.  Then change the code to default to 'slice_exec_time == exec_time' and 'slice_budget == exec_cost' for "normal" plugins that do not implement semi-partitioned policies.

The main reason why the semi-partitioned plugins never got merged into the main repository is that they added too many new fields to struct task_param. I think this is still an issue that needs to be addressed before these plugins can be merged. The idea back then was to have per-task, per-plugin data structures that are allocated only on demand and populated via 'echo XYZ > /proc/<PID>/litmus/<PLUGIN>/parameter'. I still like this idea very much, but it never got implemented because the profcs code is kind of an undocumented mess. It would be really great if anyone would like to take another shot at this… 

Thanks,
Björn





More information about the litmus-dev mailing list