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

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Oct 21, 2026 at 04:41:52PM +0300, Kayra Cizmeci wrote:
> On Wed, Oct 21, 2026 at 03:32:59PM +0200, Vincent Guittot wrote:
> > On Wed, 21 Oct 2026 at 15:13, Peter Zijlstra <peterz@infradead.org> wrote:

> > > What is the actual semantics of cpu.idle nonsense? Why do we care about
> > > this common ancestor?
> > 
> > AFAICT, cpu.idle applied to one level and against entities at the same level
> >
> 
> Yeah. Like on here:
> 
>     ROOT
>      /\
>     /  \
>    /    \
>   GA*   GB
>    |    /\
>    V   /  \
>   TA  GC*  GD
>       |    |
>       V    V
>       TB   TC

(marked GA and GC with * to denote their 'idleness')

> If GA is idle and GB is not, while GC is idle and were looking to TA and
> TB we gotta choose TB. But if we just look to GC and GA we would choose
> neither. .idle just applies to one level as Vincent says.

Yeah, that's what we used to do, but the more I think about this, the
less sense it makes! 

Josh added this (added to Cc now), but we have a number of Google folks
on Cc already. It would be good to hear how this is actually used.


So in your example TA and TB are both inside an idle group, and
therefore one can argue their behaviour should be like !idle. But their
common ancestor is root, and so the fact that they're contained in idle
groups gets lost (which seems crazeh).

But worse I think is T{AB} vs TC. In that case none of the common
ancestors (root,GB) resp. is idle. But T{AB} being inside idle should,
IMO. definitely matter vs TC, which has no idle anywhere.

So I think I would very much like to change the semantics here. The
current stuff makes no sense.

Anybody, please chime in with how this idle crap is used and expected to
work.