Hi Juri,
On Thu, 23 Aug 2018 12:23:50 +0200
Juri Lelli <juri.lelli@xxxxxxxxx> wrote:
> > sorry for the late reply (I am just back from vacations), and thanks
> > for cc-ing me.
>
> Welcome back! :-)
Thanks :)
> > I see you opened a bug on github about this, so I am going to add
> > more details there,
>
> I use github issues to keep track of things, but I guess mailing list
> discussions are to be preferred though (so that more people can
> potentially follow).
Ok
> > but basically I think that in order to use SCHED_DEADLINE as
> > non-root we need to:
> > 1) Disable the boosting mechanism (not the inheritance, just the
> > "soft enforcement behaviour" of tasks holding mutexes)
>
> But then what is a sane inheritance mechanism?
In my understanding (please correct me if I am wrong), this is an
orthogonal issue: if I understand well, the issue preventing non-root
usage of SCHED_DEADLINE is that a task inheriting a dl entity is not
throttled (when the current runtime rrives to 0, the deadline is
postponed, but the task stays schedulable). So, I think that removing
this behaviour should allow to use SCHED_DEADLINE without starving
other tasks...
Then, there is the issue about the deadline and runtime to inherit. And
I agree that this is important (and the solution is not easy), but you
have this issue even if you use the current "dl_boosted" behaviour...
No?
> Walk the chain and find
> the next potential deadline to inherit for the current boosted (still
> runtime enforced) task before throttling it? Not sure it's going to be
> any easier than the proxy solution. :-/
Right; this is not easy... But I think it is not related with the issue
we are discussing (if I understand this email thread well). Yes, it has
to be fixed, but it does not prevent non-root usage. Or am I missing
something?
> > 2) Implement some mechanism to limit the amount of dl bandwidth a
> > user can allocate to itself (I think the cgroup-based approach we
> > discussed some time ago should be OK... If I remember well, you
> > even had a patch implementing it :)
>
> I think most (all?) distributions today run with CONFIG_RT_GROUP_SCHED
> disabled, we should also think about a solution that doesn't rely on
> that interface.
I guess CONFIG_RT_GROUP_SCHED is often disabled because it ends up
changing the "traditional" SCHED_{RR/FIFO} behaviour. So, maybe the
solution is to have a different dl_{runtime,period} interface in
control groups (enabled by CONFIG_DL_GROUP_SCHED :).
CONFIG_DL_GROUP_SCHED does not change the scheduling behaviour, but
only the admission test... So, enabling it could be safer than enabling
CONFIG_RT_GROUP_SCHED.
> Maybe the existing system wide sched_rt_{period,
> runtime}_us are enough?
I do not know... A cgroup-based interface looks more powerful (and not
so difficult to implement... :), and would allow the sysadmin to decide
which users can use SCHED_DEADLINE, how much SCHED_DEADLINE bandwidth
can each user/group use, etc...
Luca
