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

[Peter Zijlstra <peterz@infradead.org>]

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.