Re: [PATCH v10 7/7] sched: Split scheduler and execution contexts

[Qais Yousef <qyousef@layalina.io>]

On 05/06/24 21:54, John Stultz wrote:
> From: Peter Zijlstra <peterz@infradead.org>
> 
> Let's define the scheduling context as all the scheduler state
> in task_struct for the task selected to run, and the execution
> context as all state required to actually run the task.
> 
> Currently both are intertwined in task_struct. We want to
> logically split these such that we can use the scheduling
> context of the task selected to be scheduled, but use the
> execution context of a different task to actually be run.
> 
> To this purpose, introduce rq_selected() macro to point to the
> task_struct selected from the runqueue by the scheduler, and
> will be used for scheduler state, and preserve rq->curr to
> indicate the execution context of the task that will actually be
> run.

This is subjective opinion of course. But I am not a fan of rq_selected().
I think we are better with more explicit

	rq->currs	/* current sched context */
	rq->currx	/* current execution context */

and the helpers

	task_curr_sctx()
	task_curr_xctx()

This will ensure all current users of rq->curr will generate a build error and
be better audited what they are supposed to be. And I think the code is more
readable this way.

Another way to do it is to split task_struct to sched and exec context (rather
than control the reference to curr as done here). Then curr would be always the
same, but reference to its sched context would change with inheritance.

ie:

	struct task_sctx {
		...
	};

	struct task_struct {
		struct task_sctx *sctx;
		/* exec context is embedded as-is */
		...
	};

Which means would just have to update all accessors to sched context to do
extra dereference. Which I am not sure if a problematic extra level of
indirection.

I see the latter approach  more intuitive and explicit about what is a sched
context that is supposed to be inherited and what is not.

I generally think breaking down task structure would be good. Hopefully the new
data perf can help us make better decision on what attributes to group
together. And generally this might be a good exercise to rethink its content
which grown organicaly over the year. Maybe we want to create similar such
smaller wrapper structs for other fields too.

I **think** with this approach we would just need go fix compilation errors to
do p->sctx->{attribute}.

Proxy exec later would only update the reference to this struct to enforce
inheritance for rq->curr->sctx to point to the donor's context.