[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <xhsmhecrehcmz.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
Date: Tue, 07 Oct 2025 18:58:44 +0200
From: Valentin Schneider <vschneid@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>, tj@...nel.org
Cc: linux-kernel@...r.kernel.org, peterz@...radead.org, mingo@...nel.org,
juri.lelli@...hat.com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
mgorman@...e.de, longman@...hat.com, hannes@...xchg.org, mkoutny@...e.com,
void@...ifault.com, arighi@...dia.com, changwoo@...lia.com,
cgroups@...r.kernel.org, sched-ext@...ts.linux.dev, liuwenfang@...or.com,
tglx@...utronix.de
Subject: Re: [PATCH 01/12] sched: Employ sched_change guards
On 06/10/25 12:44, Peter Zijlstra wrote:
> @@ -7391,52 +7391,42 @@ void rt_mutex_setprio(struct task_struct
> if (prev_class != next_class && p->se.sched_delayed)
> dequeue_task(rq, p, DEQUEUE_SLEEP | DEQUEUE_DELAYED | DEQUEUE_NOCLOCK);
>
> - queued = task_on_rq_queued(p);
> - running = task_current_donor(rq, p);
I'm not sure how that plays with sched_ext, but for the "standard" change
pattern such as this one & the others in core.c, that becomes a
task_current() per sched_change_begin(). I'm guessing we want to make
sched_change_begin() use task_current_donor() instead?
Powered by blists - more mailing lists