Re: [PATCH 06/20 v3] sched/eevdf: Add min slice check when selecting CPU

[Vincent Guittot]

On Mon, 9 Nov 2026 at 20:56, Kayra Cizmeci <kayracizmeci@xxxxxxxxx> wrote:
>
> On Mon, Nov 09, 2026 at 04:55:23PM +0100, Vincent Guittot wrote:
> > On Sat, 7 Nov 2026 at 09:57, Kayra Cizmeci <kayracizmeci@xxxxxxxxx> wrote:
> > >
> > >
> > > Hi Vincent,
> > >
> > >
> > > Sashiko reviewed this one so I'll just put here my own concerns instead
> > > of repeating.
> >
> > Regarding sashiko's feedback about cpu state ranking, I chose this
> > ranking on purpose.
> > For !SMT :
> > - 7 CPU is idle and fully fits (i.e. return immediately)
> > - 6 CPU fully fits and is not idle but we can preempt current because
> > of slice so the task will run on the best CPU immediately
> > - 5 CPU is idle but doesn't fit uclamp min. On such a CPU, the task
> > can easily miss its deadline
> > - 4 CPU is idle but doesn't fit at all. This is even worse
> >
> > For SMT
> > - 7:CPU is idle and fully fits (i.e. return immediately)
> > - 6: CPU is busy and fully fits. Although CPU is not idle, task can
> > preempt current because of its slice and run immediately on a CPU.
> > This is similar to an idle CPU (and maybe even better). While writing
> > this, I realize that I should probably check the lag too
> > - 5: CPU is idle but doesn't fit uclamp min. On such a CPU, the task
> > can easily miss its deadline
> > - 4: CPU is idle but doesn't fit at all. This is even worse than -5
> > - 3: CPU is idle and fits for task but sibling is busy
> > - 2: CPU and sibling are busy and fits for task and like-6 task will
> > run immediately
> > - 1: CPU is idle and doesn't fit uclamp and sibling is busy
> >   0: CPU is idle but doesn't fit at all, and sibling is busy.
> >
> > Note that with the push mecanism we could look for another CPU for the
> > task that will be preempted
> >
>
> Thanks for the great explanation! My only concern is on 6 and 2, as I
> explained in my first message, below.
>
> Sashiko also pointed out other concerns, it would be good to check them
> all out.

Yeah, will fix the set_idle_cores too

>
> > >
> > >
> > > Look here:
> > >
> > > CPU1: CPU2:
> > > FA    RA
> > >       FC
> > >
> > > CPU2 has 1 RT and 1 Fair tasks named RA and FC.
> > > Let's say RA is running on CPU2 and FC's slice is 10 ms.
> > >
> > > And let's say FA has 8 ms slice, and a fair task named TC is waking up
> > > with 9 ms slice:
> > >
> > > * We look to CPU1, 9 < 8 is false so we return false
> > >
> > > * We look to CPU2, 9 < 10 is true so we return it.
> > >
> > > But the problem is, CPU2 has a RT task running and we are going to
> > > compete with the RT task. In that case it can be worse than CPU1.
> > >
>
>
> Thanks,
>
> Kayra