[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230404092148.GC284733@hirez.programming.kicks-ass.net>
Date: Tue, 4 Apr 2023 11:21:48 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: linux-kernel@...r.kernel.org, Aaron Lu <aaron.lu@...el.com>
Subject: Re: [RFC PATCH] sched: Fix performance regression introduced by
mm_cid
On Mon, Apr 03, 2023 at 02:13:42PM -0400, Mathieu Desnoyers wrote:
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 0d18c3969f90..775c7da6ec7f 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2326,16 +2326,20 @@ static inline bool is_cpu_allowed(struct task_struct *p, int cpu)
> static struct rq *move_queued_task(struct rq *rq, struct rq_flags *rf,
> struct task_struct *p, int new_cpu)
> {
> + int cid;
> +
> lockdep_assert_rq_held(rq);
>
> deactivate_task(rq, p, DEQUEUE_NOCLOCK);
> set_task_cpu(p, new_cpu);
> + cid = sched_mm_cid_migrate_from(rq, p);
> rq_unlock(rq, rf);
>
> rq = cpu_rq(new_cpu);
>
> rq_lock(rq, rf);
> WARN_ON_ONCE(task_cpu(p) != new_cpu);
> + sched_mm_cid_migrate_to(rq, p, cid);
> activate_task(rq, p, 0);
> check_preempt_curr(rq, p, 0);
>
I can't find more uses? Yet there are a ton more ways to actually
migrate tasks.
Powered by blists - more mailing lists