Re: [PATCH v2] sched/deadline: Make dl-server nohz full aware

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Oct 01, 2026 at 04:27:36PM +0200, Peter Zijlstra wrote:

> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 0663c00c41c0..5388bde93410 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -401,6 +401,7 @@ static void __dl_clear_params(struct sched_dl_entity *dl_se);
>   */
>  static void task_non_contending(struct sched_dl_entity *dl_se, bool dl_task)
>  {
> +	enum hrtimer_mode mode = HRTIMER_MODE_REL_HARD;
>  	struct hrtimer *timer = &dl_se->inactive_timer;
>  	struct rq *rq = rq_of_dl_se(dl_se);
>  	struct dl_rq *dl_rq = &rq->dl;
> @@ -459,8 +460,10 @@ static void task_non_contending(struct sched_dl_entity *dl_se, bool dl_task)
>  	dl_se->dl_non_contending = 1;
>  	if (!dl_server(dl_se))
>  		get_task_struct(dl_task_of(dl_se));
> +	else
> +		mode |= HRTIMER_MODE_PINNED;
>  
> -	hrtimer_start(timer, ns_to_ktime(zerolag_time), HRTIMER_MODE_REL_HARD);
> +	hrtimer_start(timer, ns_to_ktime(zerolag_time), mode);
>  }
>  
>  static void task_contending(struct sched_dl_entity *dl_se, int flags)
> @@ -1061,6 +1064,7 @@ static inline u64 dl_next_period(struct sched_dl_entity *dl_se)
>   */
>  static int start_dl_timer(struct sched_dl_entity *dl_se)
>  {
> +	enum hrtimer_mode mode = HRTIMER_MODE_ABS_HARD;
>  	struct hrtimer *timer = &dl_se->dl_timer;
>  	struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
>  	struct rq *rq = rq_of_dl_rq(dl_rq);
> @@ -1112,7 +1116,9 @@ static int start_dl_timer(struct sched_dl_entity *dl_se)
>  	if (!hrtimer_is_queued(timer)) {
>  		if (!dl_server(dl_se))
>  			get_task_struct(dl_task_of(dl_se));
> -		hrtimer_start(timer, act, HRTIMER_MODE_ABS_HARD);
> +		else
> +			mode |= HRTIMER_MODE_PINNED;
> +		hrtimer_start(timer, act, mode);
>  	}
>  
>  	return 1;

Bah, this would require something like:

  hrtime_start_on(timer, act, mode, rq->cpu);

which we don't currently have. The problem is that on remote enqueue, we
can start the dl-server remotely, and it then being pinned, means its on
the 'wrong' CPU.

Doing remote hrtimer_start isn't entirely trivial either. So scrap this
for now :-(