Re: [Question] SCHED_DEADLINE behavior when HRTICK_DL is disabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [RT Stable]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux