Re: [PATCH v4] sched: Provide USF for the portable equipment.

[Qais Yousef]

On 08/05/20 03:33, Dongdong Yang wrote:
> Appreciate Qais for your above comments. I believe the clamp is very good for
> terminal devices per pid or cgroup setting. I really hope it works for the
> extended scenario, "screen off", although it has a potential side effect on
> "screen on" response because it needs to be recovered  at high level with
> latency. I set  "512" to sched_util_clamp_min and max on screen off for our
> developing device with android kernel5.4. However, it still could not
> replace sched_usf_non_ux_r from the test result as attachment. The cpufreq
> could not go down in time. 
> Screenshot at 2020-08-05 09:56:38.png

Please fix your email client so that it doesn't send in HTML. LKML will reject
HTML emails.

I can't interpret the numbers in the pictures. Can you help explain what am
I looking at?

I did see an issue with frequency not capped immediately when the system was
busy. I am still trying to debug that. I already fixed one problem related to
iowait boost not honouring uclamp requests, I will be posting a patch for this
soon. If you have IO heavy workload, then iowait boost will cause schedutil to
run at high frequency, and uclamp capping is not applied in that path.

Can you trace what happens inside uclamp_rq_util_with() when it's called from
sched_cpu_util()? The clamp should be applied quickly, so it's a bug we need to
fix. In my case I noticed if I ctrl+Z then `fg`, the cap is applied. My hands
are full to look at this soon. So if you can trace it, that'd be great.

Can you expand more on your worry for "screen on"? The only latency I see is
userspace not being able to set uclamp values quickly. But since it seems you
already can set sched_usf_non_ux_r from userspace with acceptable results, then
uclamp should be able to cover the same functionality. What am I missing?

Thanks

--
Qais Yousef