Dear Juri,
just a small comment for the next round of patches (I guess after
OSPM)...
On 091018, 11:24, Juri Lelli 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::proxy to point to the task_struct used
> for scheduler state and preserve rq::curr to denote the execution
> context.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> [added lot of comments/questions - identifiable by XXX]
> Signed-off-by: Juri Lelli <juri.lelli@xxxxxxxxxx>
> ---
> kernel/sched/core.c | 62 ++++++++++++++++++++++++++++++++++----------
> kernel/sched/fair.c | 4 +++
> kernel/sched/sched.h | 30 ++++++++++++++++++++-
> 3 files changed, 82 insertions(+), 14 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index fe0223121883..d3c481b734dd 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -224,12 +224,13 @@ static enum hrtimer_restart hrtick(struct hrtimer *timer)
> {
> struct rq *rq = container_of(timer, struct rq, hrtick_timer);
> struct rq_flags rf;
> + struct task_struct *curr = rq->proxy;
You may want to use a different naming for these local variables (e.g.
"proxy") to help the reader in not confusing curr (i.e. scheduling ctx)
with rq::curr (i.e. execution ctx).
Best regards,
Claudio
