Re: [PATCH 03/12] sched_ext: Split curr|donor references properly

[Andrea Righi]

Hi Maria,

On Fri, Jul 03, 2026 at 02:10:05PM +0800, Aiqun(Maria) Yu wrote:
> On 7/3/2026 1:09 AM, Andrea Righi wrote:
> > From: John Stultz <jstultz@xxxxxxxxxx>
> > 
> > With proxy-exec, we want to do the accounting against the donor most of
> > the time. Without proxy-exec, there should be no difference as the
> > rq->donor and rq->curr are the same.
> 
> Trying to understand more of the situation when donor and curr in
> different sched_class? one is in scx and the other is not.
>  could you pls help to explain more with this information in commit message?

Sure, I'll add more details. Do you think something like the following would
help (maybe in a shorter form)?

Let use FAIR and EXT and assume we run the BPF scheduler in partial mode. We can
replace FAIR with RT/deadline, the result is the same.

Terminology:

  D = blocked donor
  M = mutex
  O = mutex owner
  T = competing runnable task

 D -----------------> M -------------> O ----------------> T
 [donor] blocked on [mutex] owned by [owner] preempted by [task]
    \_________________________________^
         donates scheduling context

During a proxy exec switch:
 - D supplies scheduling class, priority and runtime budget
 - O is the task whose code is physically executing
 - T is a competing task that preempts O

Scenarios:

 1) D is EXT, O is EXT, T is EXT

    Result:
    - D can interrupt T depending on the BPF scheduling policy
    - O is executed with D's EXT priority and runtime budget
    - When D runs, T waits in EXT

 2) D is EXT, O is EXT, T is FAIR

    Result:
    - D is visible to the BPF scheduler
    - D cannot preempt T (EXT < FAIR)
    - Once T stops, BPF dispatches D
    - D executes O using D's EXT priority and runtime budget
    - if T becomes runnable again, it preempts the D/O proxy execution

 3) D is EXT, O is FAIR, T is EXT

    Result:
    - Not possible, T can't preempt O (EXT < FAIR)

 4) D is EXT, O is FAIR, T is FAIR

    Result:
    - D cannot boost O because EXT < FAIR
    - O and T continue competing under FAIR
    - O eventually runs and releases M
    - D then wakes and resumes normal EXT scheduling

 5) D is FAIR, O is EXT, T is EXT

    Result:
    - D preempts T immediately (higher sched class)
    - O is executed with D's FAIR priority and runtime budget
    - When D runs, T waits in EXT
    - D is not visible to the BPF scheduler

 6) D is FAIR, O is EXT, T is FAIR

    Result:
    - D runs based on its FAIR deadline (competing with T)
    - O is executed with D's FAIR priority and runtime budget
    - When D runs, T waits in FAIR
    - D is not visible to the BPF scheduler

 7) D is FAIR, O is FAIR, T is EXT

    Result:
    - Not possible, T can't preempt O (EXT < FAIR)

 8) D is FAIR, O is FAIR, T is FAIR

    Result:
    - O, T and D all have FAIR scheduling contexts
    - D remains runnable as a blocked proxy donor
    - When CFS selects D, O executes using D's FAIR scheduling context
    - When CFS selects O, O executes using its own FAIR context
    - When CFS selects T, T executes normally
    - D is not visible to the BPF scheduler

> 
> > 
> > So rework the logic to reference the rq->donor where appropriate.
> > 
> > Also add donor info to scx_dump_state().
> > 
> > Since CONFIG_SCHED_PROXY_EXEC currently depends on
> > !CONFIG_SCHED_CLASS_EXT, this should have no effect (other than the
> > extra donor output in scx_dump_state), but this is one step needed to
> > eventually remove that constraint for proxy-exec.
> > 
> > Signed-off-by: John Stultz <jstultz@xxxxxxxxxx>
> > ---
> >  kernel/sched/ext/ext.c | 28 ++++++++++++++++------------
> >  1 file changed, 16 insertions(+), 12 deletions(-)
> > 
> > diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> > index 1a0ec985da77d..1588565050679 100644
> > --- a/kernel/sched/ext/ext.c
> > +++ b/kernel/sched/ext/ext.c
> > @@ -1145,17 +1145,17 @@ static void touch_core_sched_dispatch(struct rq *rq, struct task_struct *p)
> >  
> >  static void update_curr_scx(struct rq *rq)
> >  {
> > -	struct task_struct *curr = rq->curr;
> > +	struct task_struct *donor = rq->donor;
> >  	s64 delta_exec;
> >  
> >  	delta_exec = update_curr_common(rq);
> >  	if (unlikely(delta_exec <= 0))
> >  		return;
> >  
> > -	if (curr->scx.slice != SCX_SLICE_INF) {
> > -		curr->scx.slice -= min_t(u64, curr->scx.slice, delta_exec);
> > -		if (!curr->scx.slice)
> > -			touch_core_sched(rq, curr);
> > +	if (donor->scx.slice != SCX_SLICE_INF) {
> > +		donor->scx.slice -= min_t(u64, donor->scx.slice, delta_exec);
> > +		if (!donor->scx.slice)
> > +			touch_core_sched(rq, donor);
> >  	}
> >  
> >  	dl_server_update(&rq->ext_server, delta_exec);
> > @@ -1316,8 +1316,8 @@ static void local_dsq_post_enq(struct scx_sched *sch, struct scx_dispatch_q *dsq
> >  	if (rq->scx.flags & SCX_RQ_IN_BALANCE)
> >  		return;
> >  
> > -	if ((enq_flags & SCX_ENQ_PREEMPT) && p != rq->curr &&
> > -	    rq->curr->sched_class == &ext_sched_class) {
> > +	if ((enq_flags & SCX_ENQ_PREEMPT) && p != rq->donor &&
> > +	    rq->donor->sched_class == &ext_sched_class) {
> >  		rq->curr->scx.slice = 0;
> 
> Do you forget to update rq->curr with rq->donor here?

Yes, good catch. This should be rq->donor->scx.slice = 0. I'll fix it in the
next version.

Thanks,
-Andrea