Re: [PATCH v4 07/13] sched: Split scheduler execution context

[Dietmar Eggemann]

On 01/06/2023 07:58, John Stultz wrote:
> From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> 
> Lets define the scheduling context as all the scheduler state in
> task_struct and the execution context as all state required to run
> the task.
> 
> Currently both are intertwined in task_struct. We want to logically
> split these such that we can run the execution context of one task
> with the scheduling context of another.
> 
> To this purpose introduce rq_selected() macro to point to the
> task_struct used for scheduler state and preserve rq->curr to
> denote the execution context.
> 
> NOTE: Peter previously mentioned he didn't like the name
> "rq_selected()", but I've not come up with a better alternative.
> I'm very open to other name proposals.
> 
> Question for Peter: Dietmar suggested you'd prefer I drop the
> conditionalization of the scheduler context pointer on the rq
> (so rq_selected() would be open coded as rq->curr_sched or
> whatever we agree on for a name), but I'd think in the
> !CONFIG_PROXY_EXEC case we'd want to avoid the wasted pointer
> and its use (since it curr_sched would always be == curr)?
> If I'm wrong I'm fine switching this, but would appreciate
> clarification.

IMHO, keeping both, rq->curr and rq->proxy (latter for rq->curr_sched)
would make it easier to navigate through the different versions of this
patch-set while reviewing.

I do understand that you have issues with the function name proxy() not
returning the proxy (task blocked on a mutex) but the mutex owner instead.

The header of v3 'sched: Add proxy execution'
https://lkml.kernel.org/r/20230411042511.1606592-12-jstultz@xxxxxxxxxx
mentions:

" ... Potential proxies (i.e., tasks blocked on a mutex) are not
  dequeued, so, if one of them is actually selected by schedule() as the
  next task to be put to run on a CPU, proxy() is used to walk the
  blocked_on relation and find which task (mutex owner) might be able to
  use the proxy's scheduling context. ..."

But as I can see now, you changed this patch header in v4 to explain the
PE model slightly differently.

[...]