[LITMUS^RT] sys_set_rt_task_param() race

[Björn Brandenburg]

> On 13 Jan 2017, at 21:42, Björn Brandenburg <bbb at mpi-sws.org> wrote:
> 
> 
>> On 13 Jan 2017, at 21:18, Chen, Tianyang <tiche at seas.upenn.edu> wrote:
>> 
>> The syscall sys_set_rt_task_param() in litmus/litmus.c cannot change a real-time task's parameters due to potential race with the scheduler, according the comments below:
>> 
>> "Only non-real-time tasks may be configured with this system call to avoid races with the scheduler. In practice, this means that a task's parameters must be set _before_ calling sys_prepare_rt_task()”
> 
> This is an old limitation inherited from the early days of LITMUS^RT that has never been relaxed. The “race” warning just means that none of the scheduler plugins expect that task parameters could change. 
> 
>> I can't think of anything that needs to be fixed other than an already armed hrtimer for budget enforcement. For example, if a job is running and before the budget enforcement timer fires, someone refills the budget.
> 
> The plugin may have allocated or configured parameter-specific data structures. For instance, this is the case with the Pfair plugin.
> 
>> This can be taken care of by re-programming the hrtimer during refills. If someone wants to abort the current job immediately, the exec_time can be manipulated so when the scheduler is called, out_of_time will be set to true.
>> 
>> I'm trying add a new syscall to update a rt_task's paramters, such as period and budget of EDF. The "race" with a scheduler sounds like a serious issue. Is there any other things that I'm overlooking? Thanks.
> 
> It probably works with EDF. I actually coded up a patch at some point to change job parameters at runtime. Let me see if I can dig it up.

Found it. I pushed my (trivial) patches to the branch wip-change-params-at-runtime.

	https://github.com/LITMUS-RT/litmus-rt/commits/wip-change-params-at-runtime

This is just the core infrastructure change. You’ll need to add a callback to whatever plugin you are interested in to actually enact parameter changes (e.g., while holding plugin-internal locks).

Hope that helps. Let me know if you have more questions. 

Cheers,
Björn