[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240813222548.049744955@infradead.org>
Date: Wed, 14 Aug 2024 00:25:48 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: mingo@...nel.org,
tj@...nel.org,
void@...ifault.com
Cc: peterz@...radead.org,
juri.lelli@...hat.com,
vincent.guittot@...aro.org,
dietmar.eggemann@....com,
rostedt@...dmis.org,
bsegall@...gle.com,
mgorman@...e.de,
vschneid@...hat.com,
linux-kernel@...r.kernel.org,
joelaf@...gle.com
Subject: [PATCH 0/9] sched: Prepare for sched_ext
Hi,
These patches apply on top of the EEVDF series (queue/sched/core), which
re-arranges the fair pick_task() functions to make them state invariant such
that they can easily be restarted upon picking (and dequeueing) a delayed task.
This same is required to push (the final) put_prev_task() beyond pick_task(),
like we do for sched_core already.
This in turn is done to prepare for sched_ext, which wants a final callback to
be in possesion of the next task, such that it can tell if the context switch
will leave the sched_class.
As such, this all re-arranges the current order of:
put_prev_task(rq, prev);
next = pick_next_task(rq); /* implies set_next_task(.first=true); */
to sometihng like:
next = pick_task(rq)
if (next != prev) {
put_prev_task(rq, prev, next);
set_next_task(rq, next, true);
}
The patches do a fair bit of cleaning up. Notably a bunch of sched_core stuff
-- Joel, could you please test this stuff, because the self-tests we have are
hardly adequate.
The EEVDF stuff was supposed to be merged already, but since Valentin seems to
be doing a read-through, I figured I'd give him a little extra time. A complete
set can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/prep
Powered by blists - more mailing lists