Allow non-root usage of SCHED_DEADLINE

[jlelli]

SCHED_DEADLINE is currently only available to root users.
This however it's hindering adoption on applications (e.g., pro-audio) that run with normal privileges.
Main problem to safely relax privileges requirement is to implement a saner priority inheritance mechanism, as boosted threads are currently outside bandwidth enforcement.

[jlelli]

I actually seem to remember that @lucabe72 had in mind a possible (temporary?) alternative to still be safe without implementing bandwidth inheritance?

[lucabe72]

In my opinion, these are the possible alternatives (in increasing order of complexity):

1. Disable the "dl_boosted" mechanism: even if a task is inheriting a deadline from another task, when its budget is exhausted the task is throttled. This will affect the average performance of dl tasks using mutexes, but will not impact the worst-case behaviour (which is the important thing for real-time performance)
2. Disable the "dl_boosted" mechanism for tasks inheriting deadlines from non-root tasks. This will leave the root tasks behaviour unmodified (so, no regressions respect to the current situation), but will allow to create non-root deadline tasks that cannot starve non-deadline tasks (because they are throttled even if in critical section)
3. Add runtime inheritance to the current deadline inheritance, in order to somehow emulate BWI... This will require to remove the "dl_boosted" code, which is the source of the issue. I had an almost-working patch for this... If needed, I can search for it and try to port it to tip master
4. Implement BWI (the single-CPU version, not the full m-BWI)
5. Implement m-BWI. But this open the other can of worms about busy-waiting :)

[jlelli]

3. Add runtime inheritance ...
   I can search for it

If it's not too much trouble it would be interesting to have a look, sure. Even without forward porting it.

However, I'm wondering why this "intermediate" approach doesn't have the same theoretical problems that a full (m-)BWI implementation might have.

Also, could you quickly remember to me why the busy-waiting was needed (guess I should read again the paper :-))? And so why it wouldn't be needed if we go for option 3?

[lucabe72]

On Tue, 28 Aug 2018 at 17:08, Juri Lelli ***@***.***> wrote: 1. Add runtime inheritance ... I can search for it If it's not too much trouble it would be interesting to have a look, sure. Even without forward porting it.

Ok, tomorrow I'll try to search for it in my old hard disk... But it was a quite simple patch (not considering multiple inheritance, for example) However, I'm wondering why this "intermediate" approach doesn't have the

same theoretical problems that a full (m-)BWI implementation might have.

Well, actually it was just a simple fix for some strange behaviours I found in the current deadline inheritance code (mixing relative and absolute deadlines, etc...). It has drawbacks (for example, I have no theoretical schedulability analysis for it), but I think it is better than the current code (notice that the current inheritance code does not provide any kind of guarantee to deadline tasks). For m-BWI there is a schedulability analysis (and I think that something can be done for BWI too), so (m-)BWI is a more theoretically sound solution (the theoretical problems of (m-)BWI are there to provide some kind of performance guarantee that can be used for theoretical schedulability analysis) . Answering your question, my runtime inheritance patch had theoretical problems (no analysis), but had the big advantage of being simpler than a full BWI / m-BWI... Also, could you quickly remember to me why the busy-waiting was needed

(guess I should read again the paper :-))? And so why it wouldn't be needed if we go for option 3?

Well, I am not one of the m-BWI authors, so I do not know why the decided to use busy waiting, but I know the issue that it addresses: the theoretical schedulability analysis of BWI relies on a specific property: when the task served by a server has a pending (arrived but not finished) job, the server is active/schedulable (even if the job is blocked on a mutex). When the job blocks on a mutex, the server serves the mutex owner. This works fine with BWI on uni-processor systems, but in presence of multiple processors a task running on processor 0 can block on a mutex owned by the earliest deadline task of processor 1... In this case, the server of the task cannot be used to serve the mutex owner (because it is already served by its own server)... So, m-BWI spins until the mutex is free (so that the server can be used to serve the spinning task). In other words, the busy-waiting is used to avoid breaking a property needed for theoretical analysis (of course, other solutions are possible).

…

[lucabe72]

Sorry, I cannot find my old patch on the hard disk - probably something went wrong with backups when moving from Trento to Pisa :(

Anyway, the patch was based on fixing the fact that "pi_se" is computed based on absolute deadlines (which is correct), but then its relative deadline (and runtime) is used to replenish the "dl_se" runtime and postpone the "dl_se" deadline (and I think this is wrong).

So, this is what I did (at least, this is what I remember about what I did :):

• I added two "orig_deadline" and "orig_runtime" fields to the dl entity
• When "pi_se" is not null, I set dl_se->orig_deadline = dl_se->deadline; dl_se->deadline = pi_se->deadline (same for runtime)
• When updating "dl_se->runtime" and "dl_se->deadline", I used the "pi_se" relative deadline and maximum runtime, but if "dl_se->deadline > dl_se->orig_deadline" I restored the original values
• I disabled the soft enforcement behaviour when "dl_se->dl_boosted = 1" (I remember my original idea was to remove dl_boosted, but then I decided to use it in order to check if the task is inheriting runtime and deadline)

This is more or less what I did... Sorry for losing the patch :( Anyway, as you can see it is not a complex patch; I can rewrite it if needed.