[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250613094328.GG2278213@noisy.programming.kicks-ass.net>
Date: Fri, 13 Jun 2025 11:43:28 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Juri Lelli <juri.lelli@...hat.com>
Cc: mingo@...hat.com, vincent.guittot@...aro.org, dietmar.eggemann@....com,
rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
vschneid@...hat.com, clm@...a.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 1/5] sched/deadline: Less agressive dl_server
handling
On Tue, Jun 03, 2025 at 06:03:12PM +0200, Juri Lelli wrote:
> Hi,
>
> > @@ -1684,6 +1689,24 @@ void dl_server_stop(struct sched_dl_enti
> > dl_se->dl_server_active = 0;
> > }
> >
> > +static bool dl_server_stopped(struct sched_dl_entity *dl_se)
> > +{
> > + if (!dl_se->dl_server_active)
> > + return false;
> > +
> > + if (dl_se->dl_server_idle) {
> > + __dl_server_stop(dl_se);
> > + return true;
> > + }
> > +
> > + dl_se->dl_server_idle = 1;
> > + return false;
> > +}
> > +
> > +void dl_server_stop(struct sched_dl_entity *dl_se)
> > +{
> > +}
>
> What if we explicitly set the server to idle (instead of ignoring the
> stop) where this gets called in dequeue_entities()?
That would break thing; we want to detect if it was ever !idle in the
period.
> Also, don't we need to actually stop the server if we are changing its
> parameters from sched_fair_server_write()?
Quite - let me just remove the offending callsites them.
Would this explain this massive regression 0day reported here? Seems
weird.
Anyway, let me go update the patch.
Powered by blists - more mailing lists