Re: [RFC][PATCH 3/3] sched/eevdf: Fix sched idle task group preemption

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Nov 12, 2026 at 01:31:19PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 10, 2026 at 09:51:21AM -0800, Josh Don wrote:
> > On Tue, Nov 10, 2026 at 6:20 AM Kayra Cizmeci <kayracizmeci@gmail.com> wrote:
> > >
> > > Hi Josh!
> > >
> > > On Mon, Nov 09, 2026 at 04:10:30PM -0800, Josh Don wrote:
> > >
> > > > >  /*
> > > > > - * Preempt the current task with a newly woken task if needed:
> > > > > + * Preempt an idle entity in favor of a non-idle entity (and don't preempt
> > > > > + * in the inverse case).
> > > > > + */
> > > > > +static inline enum preempt_wakeup_action
> > > > > +wakeup_preempt_sched_idle(struct sched_entity *cse, struct sched_entity *pse)
> > > > > +{
> > > > > +       int cse_is_idle, pse_is_idle;
> > > > > +
> > > > > +       cse_is_idle = se_is_idle(cse);
> > > > > +       pse_is_idle = se_is_idle(pse);
> > > > > +
> > > > > +       if (cse_is_idle || pse_is_idle) {
> > > > > +               find_matching_se(&cse, &pse);
> > > > > +               WARN_ON_ONCE(!pse);
> > > > > +
> > > > > +               cse_is_idle = se_is_idle(cse);
> > > > > +               pse_is_idle = se_is_idle(pse);
> > > >
> > > > now that se_is_idle() is checking for any ancestors with idle, this
> > > > doesn't appear to be correct. Some motivaing examples:
> > >
> > > So we want to keep the idle difference between groups with idle
> > > ancestors? FWIW, I asked about this but then thought it was knowingly
> > > and that was what we wanted. I'm still not sure what we want...
> > 
> > cgroup properties are cgroup hierarchy position relative, this just
> > maintins that behavior for cpu.idle as well. There was a more
> > extensive discussion on this in the previous RFC, which is how we
> > landed back on the find_matching_se() restoration.
> 
> Well, I'm still not convinced we need this.
> 
> Realistically idle means: "don't care, run whenever you have a minute".
> To then preempt such a task for another such a task just because its
> somewhere else in the hierarchy makes no sense, you don't care about
> either of them, we shouldn't be preempting.
> 
> Anyway, I've pushed out the first two patches to queue/sched/urgent
> since they address the worst of it. We can chew on all this a bit more I
> suppose. But I cannot convince myself that there is any situation in
> which we (should) actually care about the timeliness of anything in a
> cgroup::idle container.

Perhaps even to the point that we should have idle (either the task or
the cgroup property) imply an extra long slice length, much like how it
implies a very low weight.