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