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
+
/*
* 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).
--
2.19.0
I notice that this check is added in userspace applications
(https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/tree/src/sched_deadline/cyclicdeadline.c#n1217)
but it should also probably be there in the kernel as well?
I would like to know if there's a gap in my understanding or if this is
a valid change that can be needed.
Thanks in advance!
Sharan
