[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fd5d06cd-bda5-0e3e-5f90-d3c5464bfcad@arm.com>
Date: Tue, 13 Jun 2023 19:12:19 +0200
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: John Stultz <jstultz@...gle.com>,
LKML <linux-kernel@...r.kernel.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Joel Fernandes <joelaf@...gle.com>,
Qais Yousef <qyousef@...gle.com>,
Ingo Molnar <mingo@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Valentin Schneider <vschneid@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>,
Zimuzo Ezeozue <zezeozue@...gle.com>,
Youssef Esmat <youssefesmat@...gle.com>,
Mel Gorman <mgorman@...e.de>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Will Deacon <will@...nel.org>,
Waiman Long <longman@...hat.com>,
Boqun Feng <boqun.feng@...il.com>,
"Paul E . McKenney" <paulmck@...nel.org>, kernel-team@...roid.com,
Connor O'Brien <connoro@...gle.com>
Subject: Re: [PATCH v4 07/13] sched: Split scheduler execution context
On 01/06/2023 07:58, John Stultz wrote:
> From: Peter Zijlstra <peterz@...radead.org>
>
> 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@google.com
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.
[...]
Powered by blists - more mailing lists