[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251007093452.GC3245006@noisy.programming.kicks-ass.net>
Date: Tue, 7 Oct 2025 11:34:52 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>
Cc: linux-kernel@...r.kernel.org, mingo@...hat.com, juri.lelli@...hat.com,
vincent.guittot@...aro.org, dietmar.eggemann@....com,
rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
vschneid@...hat.com, 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,
tj@...nel.org
Subject: Re: [PATCH 01/14] sched: Employ sched_change guards
On Tue, Oct 07, 2025 at 10:42:29AM +0530, Shrikanth Hegde wrote:
> On 10/6/25 11:44 PM, Peter Zijlstra wrote:
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -10783,6 +10783,12 @@ struct sched_change_ctx *sched_change_be
> > struct sched_change_ctx *ctx = this_cpu_ptr(&sched_change_ctx);
> > struct rq *rq = task_rq(p);
> > + /*
> > + * Must exclusively use matched flags since this is both dequeue and
> > + * enqueue.
> > + */
>
> yes. Something like that. Unless callsites explicitly change the flags using
> the scope, enqueue will happen with matching flags.
>
> > + WARN_ON_ONCE(flags & 0xFFFF0000);
> > +
>
> A mythical example:
> scope_guard(sched_change, p, DEQUEUE_THROTTLE)
> scope->flags &= ~DEQUEUE_THROTTLE;
> scope->flags |= ENQUEUE_HEAD;
>
> But, One could still do this right? for such users the warning may be wrong.
Right, I suppose this would be possible. Lets worry about it if/when it
ever comes up though.
Powered by blists - more mailing lists