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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
