Re: [PATCH 4/6] sched_ext: bypass mode shouldn't depend on ops.select_cpu()

[David Vernet <void@manifault.com>]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

On Thu, Oct 10, 2024 at 08:26:27AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Thu, Oct 10, 2024 at 01:15:17PM -0500, David Vernet wrote:
> > On Wed, Oct 09, 2024 at 11:41:00AM -1000, Tejun Heo wrote:
> > > Bypass mode was depending on ops.select_cpu() which can't be trusted as with
> > > the rest of the BPF scheduler. Always enable and use scx_select_cpu_dfl() in
> > > bypass mode.
> > 
> > Could you please clarify why we can't trust ops.select_cpu()? Even if it
> > returns a bogus, offline, etc, CPU, shouldn't core.c take care of
> > finding a valid CPU for us in select_fallback_rq()?
> 
> For example, if select_cpu() returns the same CPU for all threads on a
> loaded system, that CPU can get very overloaded which can lead to RCU and
> workqueue stalls which can then cascade to other failures.

Ok I see, so it's that it could make such poor scheduling decisions that
the system can't recover. Got it.

> > Assuming we really do require a valid CPU here in bypass mode, do we
> > need to reset the state of the idle masks for the case of
> > !scx_builtin_idle_enabled? The masks won't necessarily reflect the set
> > of online CPUs if we haven't been updating it, right?
> 
> I think resched_cpu() after switching each CPU into bypass mode is enough.
> That guarantees that the CPU leaves the idle state, clearing the idle state
> if set, and if the CPU is idle, it goes back into idle, setting the bit, so
> at the end, it ends up synchronized.

Yeah that sounds reasonable. Thanks for explaining.

Acked-by: David Vernet <void@manifault.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]