Re: [PATCH v5 1/4] sched: Dispatch task ticks for donor and execution classes

[Kayra Cizmeci <kayracizmeci@gmail.com>]

Hello All, :>

> Proxy execution can run a task from one scheduling class on behalf of a
> donor from another. Scheduler ticks therefore need to reach both the class
> which owns the scheduling context and the class which owns the execution
> context.

So, donor and curr's classes may be different and we should call both of their task_ticks.

> Calling the donor first preserves the existing runtime-accounting order for
> execution-context consumers. Keep the existing class-specific tick behavior
> donor-gated in this patch, so the change only introduces the new interface
> and dispatch mechanism.

Hm..

> +/*
> + * Run the scheduling-context class first so its runtime update precedes
> + * execution-context tick work. A different execution class runs second.
> + * Same-class proxy execution gets one callback; ownership-specific work
> + * can select rq->donor or rq->curr as appropriate.
> + */
> +static inline void task_tick(struct rq *rq, int queued)
> +{
> +	const struct sched_class *curr_class = rq->curr->sched_class;
> +	const struct sched_class *donor_class = rq->donor->sched_class;
> +
> +	donor_class->task_tick(rq, queued);
> +	if (sched_proxy_exec() && curr_class != donor_class)
> +		curr_class->task_tick(rq, queued);
> +}

>  #ifdef CONFIG_SCHED_HRTICK
>  /*
>   * Use HR-timers to deliver accurate preemption points.
> @@ -923,7 +939,7 @@ static enum hrtimer_restart hrtick(struct hrtimer *timer)
>  
>  	rq_lock(rq, &rf);
>  	update_rq_clock(rq);
> -	rq->donor->sched_class->task_tick(rq, rq->donor, 1);
> +	task_tick(rq, 1);
>  	rq_unlock(rq, &rf);

So. Let's assemble a senario.

rq->donor's class method will be DL, and rq->curr's will be fair. And the sched_proxy_exec() will be true.

ON THE OLD:
Only DL runs. That's all :>

ON THE NEW:
task_tick firstly runs donor's method. That's DL. Then we goto curr's class which is fair, and run that.
But because of the newly added checks, because of the donor's sched class not equals to the fair's the code just,
doesn't run. 

Wouldn't it be better to merge this patch and it's use case together?

The commit message is confusing too "Scheduler ticks therefore need to reach both the class
which owns the scheduling context and the class which owns the execution
context." But the patch doesn't do this on it's own. 

Thanks, 
Kayra