Re: Very high scheduling delay with plenty of idle CPUs

[Peter Zijlstra <peterz@infradead.org>]

On Sun, Nov 10, 2024 at 10:15:07PM -0800, Saravana Kannan wrote:

> I actually quickly hacked up the cpu_overutilized() function to return
> true during suspend/resume and the threads are nicely spread out and
> running in parallel. That actually reduces the total of the
> dpm_resume*() phases from 90ms to 75ms on my Pixel 6.

Right, so that kills EAS and makes it fall through to the regular
select_idle_sibling() thing.

> Peter,
> 
> Would you be open to the scheduler being aware of
> dpm_suspend*()/dpm_resume*() phases and triggering the CPU
> overutilized behavior during these phases? I know it's a very use case
> specific behavior but how often do we NOT want to speed up
> suspend/resume? We can make this a CONFIG or a kernel command line
> option -- say, fast_suspend or something like that.

Well, I don't mind if Vincent doesn't. It seems like a very
specific/targeted thing and should not affect much else, so it is a
relatively safe thing to do.

Perhaps a more direct hack in is_rd_overutilized() would be even less
invasive, changing cpu_overutilized() relies on that getting propagated
to rd->overutilized, might as well skip that step, no?