Re: Very high scheduling delay with plenty of idle CPUs

[Vincent Guittot]

On Mon, 11 Nov 2024 at 11:41, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> 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.

I would like to understand why all idle little cpus are not used in
saravana's example and tasks are packed on the same cpu instead.

>
> 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?