| Message ID | 9ae1d599-4514-9c22-f5a0-7176ffe98820@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [Question] SCHED_DEADLINE behavior when HRTICK_DL is disabled | expand |
On 6/6/22 09:08, Sharan Turlapati wrote: > I had a question about the task admit policy of SCHED_DEADLINE tasks when > runtimes are in the submillisecond range (which we come across quite often in RT > ) and HRTICK is disabled. > > For the kernel to be able to keep track of task runtimes in the microsecond > range, I notice that it uses HRTICK_DL. > > If HRTICK is disabled or not supported, the kernel still admits tasks with > runtimes in the microseconds range, and but since now we're relying on the > scheduler tick (which is in the order of milliseconds), these tasks overshoot > their runtime and end up getting penalized which result in their deadlines being > pushed out. > > My question is, if the kernel cannot reliably track the runtimes in the > submillisecond range without HRTICK being enabled, should it not reject these > tasks first up? something along these lines - > > --- > kernel/sched/deadline.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > index fb4255ae0b2c..0d46ae0c92ec 100644 > --- a/kernel/sched/deadline.c > +++ b/kernel/sched/deadline.c > @@ -2916,6 +2916,21 @@ bool __checkparam_dl(const struct sched_attr *attr) > if (attr->sched_runtime < (1ULL << DL_SCALE)) > return false; > > + /* > + * If sched_runtime < 1ms, then ensure that hrtick is > + * is supported/enabled. > + */ > +#ifdef CONFIG_SCHED_HRTICK > + if (attr->sched_runtime < NSEC_PER_MSEC) > + { > + if (!sched_feat(HRTICK_DL)) > + return false; > + } > +#else > + if (attr->sched_runtime < NSEC_PER_MSEC) > + return false; > +#endif > + This is not complete as it ignores the tasks where the runtime is not "round" on milliseconds. But then the problem becomes worse: to be precise in the milliseconds for throttling, the task would have to be always dispatched at the "clock tick" to be precisely accounted for. Thus, this is not the way to go. As it is now, the admission control tries to avoid problems, not to provide guarantees. The user should be aware of this, likewise, of other factors that impact this lack of precision: for example, preempt disable sections/non-preemptive kernel... --- Daniel
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index fb4255ae0b2c..0d46ae0c92ec 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -2916,6 +2916,21 @@ bool __checkparam_dl(const struct sched_attr *attr) if (attr->sched_runtime < (1ULL << DL_SCALE)) return false; + /* + * If sched_runtime < 1ms, then ensure that hrtick is + * is supported/enabled. + */ +#ifdef CONFIG_SCHED_HRTICK + if (attr->sched_runtime < NSEC_PER_MSEC) + { + if (!sched_feat(HRTICK_DL)) + return false; + } +#else + if (attr->sched_runtime < NSEC_PER_MSEC) + return false; +#endif + /* * Since we use the MSB for wrap-around and sign issues, make * sure it's not set (mind that period can be equal to zero).