Hello,
On 16/01/26 13:39, Gabriele Monaco wrote:
> Add the deadline monitors collection to validate the deadline scheduler,
> both for deadline tasks and servers.
>
> The currently implemented monitors are:
> * throttle:
> validate dl entities are throttled when they use up their runtime
> * nomiss:
> validate dl entities run to completion before their deadiline
>
> Cc: Peter Zijlstra <[email protected]>
> Reviewed-by: Nam Cao <[email protected]>
> Signed-off-by: Gabriele Monaco <[email protected]>
> ---
...
> +/*
> + * User configurable deadline threshold. If the total utilisation of deadline
> + * tasks is larger than 1, they are only guaranteed bounded tardiness. See
> + * Documentation/scheduler/sched-deadline.rst for more details.
> + * The minimum tardiness without sched_feat(HRTICK_DL) is 1 tick to
> accommodate
> + * for throttle enforced on the next tick.
> + */
> +static u64 deadline_thresh = TICK_NSEC;
> +module_param(deadline_thresh, ullong, 0644);
> +#define DEADLINE_NS(ha_mon) (pi_of(ha_get_target(ha_mon))->dl_deadline +
> deadline_thresh)
...
> +static inline u64 runtime_left_ns(struct ha_monitor *ha_mon)
> +{
> + return pi_of(ha_get_target(ha_mon))->runtime + RUNTIME_THRESH;
> +}
Why use pi_of() in above cases?
For the first, in case the macro is called while the task is actually
boosted, we then might continue to use that even after such task gets
deboosted?
For the second, current PI implementation (even if admittedly not ideal)
uses donor's static dl_runtime to replenish boosted task runtime, but
then accounting is performed again the task dynamic runtime, not the
donor's (this all will hopefully change soon with proxy exec..)?
Thanks,
Juri
