Re: Very high scheduling delay with plenty of idle CPUs

[Christian Loehle]

On 11/11/24 06:15, Saravana Kannan wrote:
[...]
>>> Can we tell the scheduler to just spread out all the tasks during
>>> suspend/resume? Doesn't make a lot of sense to try and save power
>>> during a suspend/resume. It's almost always cheaper/better to do those
>>> quickly.
>>
>> That would increase the resume latency right since each runnable task
>> needs to go through a full idle CPU selection cycle? Isn't time a
>> consideration / concern in the resume path? Unless we go through the
>> slow path, it is very likely we'll end up making the same task
>> placement decisions again?
> 
> 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.
> 
> Also, this whole email thread started because I'm optimizing the
> suspend/resume code to reduce a lot of sleeps/wakeups and the number
> of kworker threads. And with that + over utilization hack, resume time
> has dropped to 60ms.
> 
> 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.
>

Just to confirm, you essentially want to disable EAS during
suspend/resume, or does sis also not give you an acceptable
placement?

Regards,
Christian