[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJWu+oqkWmT0Pa8h7Bs32zHJqO45gaoYkP_95sa7xc8Ki2SJiA@mail.gmail.com>
Date: Sat, 17 Aug 2024 17:56:11 -0400
From: Joel Fernandes <joelaf@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: mingo@...nel.org, tj@...nel.org, void@...ifault.com, 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
Subject: Re: [PATCH 0/9] sched: Prepare for sched_ext
On Tue, Aug 13, 2024 at 6:50 PM Peter Zijlstra <peterz@...radead.org> wrote:
>
> 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.
Ah, you emailed my Google address instead of the open source address
(joel@...lfernandes.org) so I missed this. I read open source patches
only on my open source address.
Anyway I was wanting to read this entire series. I shall carve some
time next to test some of the stuff as you mentioned. For core_sched
I'll have to find a device that still requires the core-sched
mitigations (which I believe we still do).
- Joel
Powered by blists - more mailing lists