Re: [PATCH v4] sched: Provide USF for the portable equipment.
Hi Dongdong
On 08/04/20 15:50, Dongdong Yang wrote:
> +What:/sys/devices/system/cpu/sched_usf
> + /sys/devices/system/cpu/sched_usf/sched_usf_non_ux_r
> + /sys/devices/system/cpu/sched_usf/sched_usf_up_l0_r
> + /sys/devices/system/cpu/sched_usf/sched_usf_down_r
> +Date:Aug 2020
> +Contact: Linux kernel mailing list
> +Description: User Sensitive Feedback factor auxiliary scheduling which
> + is providing more utils adjustment settings to the high level
> + by scenario identification.
> + sched_usf_non_ux_r:
> + The ratio of utils is cut down on screen off. The
> + default value is 0, which no util is adjusted on sugov
> + calculating utils to select cpufreq. Its range is
> + [-100 , 0]. If its value falls into [-50, 0), the half
> + of utils, which calculates cpufreq, shall be cut down.
> + If its value falls into [-100, -50), only a quarter of
> + utils are left to continue to calculate cpufreq.
> + It is expected to be set [-100, 0) once enter into the
> + identificated scenario, such as listen to music on
> + screen off, and recover to 0 on out of the scenario,
> + such as screen on.
> +
> + sched_usf_up_l0_r:
> + The ratio of utils is boost up on screen on. The
> + default value is 0, which no util is adjusted on sugov
> + calculates utils to select cpufreq. Its range is [0 ,
> 100].
> + If its value falls into (0, 50], a quarter of extra
> utils,
> + which calculate cpufreq, shall be added. If its value
> + falls into (50, 100], the half of extra utils are added
> + to continue to calculate cpufreq.
> + It is expected to be set (0, 100] once enter into the
> + identificated scenario, such as browsing videolet on
> + screen on, and recover to 0 on out of the scenario,
> + such as screen off or videolet into background.
> +
> + sched_usf_down_r:
> + The ratio of utils is cut down on screen on. The
> + default value is 0, which no util is adjusted on sugov
> + calculating utils to select cpufreq. Its range is
> + [-100 , 0]. If its value falls into [-50, 0), the half
> + of utils, which calculate cpufreq, shall be cut down.
> + If its value falls into [-100, -50), only a quarter of
> + utils are left to continue to calculate cpufreq.
> + It is expected to be set [-100, 0) once enter into the
> + identificated scenario, such as browsing videolet on
> + screen on, and recover to 0 on out of the scenario,
> + such as screen off or vidolet into background.
AFACS you're duplicating util clamp functionality here. You can already use
util clamp to boost tasks on screen on, and cap them on screen off. And extra
brownie points; you can already use that on android 4.19 and 5.4 kernels (I'm
assuming the battery device is android based, sorry).
Any reason why util clamp isn't giving you what you want?
To cap the system on screen off you need to
# Don't allow the util to go above 512
echo 512 > /proc/sys/kernel/sched_util_clamp_min
echo 512 > /proc/sys/kernel/sched_util_clamp_max
To boost the system on screen on, you need first to lift the capping done above
# Allow util to use the full range again
echo 1024 > /proc/sys/kernel/sched_util_clamp_min
echo 1024 > /proc/sys/kernel/sched_util_clamp_max
# This is pseudo C code
for_each_important_task(p) {
/*
* boost the task utilization to start from 512.
*/
sched_attr attr = {
.util_min = 512,
.util_max = 1024
};
sched_setattr(p, attr);
}
/* undo boosting once system has settled down */
for_each_important_task(p) {
/*
* reset util_min back to 0, or whatever value you want.
*/
sched_attr attr = {
.util_min = 0,
.util_max = 1024
};
sched_setattr(p, attr);
}
There's a cgroup API for util clamp too.
Thanks
--
Qais Yousef
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] sched: Provide USF for the portable equipment.
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 de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] sched: Provide USF for the portable equipment.
On 08/05/20 19:13, Dongdong Yang wrote: > Appreciate Qais for your clamp implementation. I would like to add traces > for uclamp_rq_util_with and feedback you if I run into any issues. Thanks. FYI, top posting in LKML is frowned upon. Please put your answer underneath the quoted text. > > The util would not be adjusted as soon as FB screen on notification be > received by USF from kernel level if it is set by sched_usf_non_ux, no > matter whether screen on or off. However, sched_util_clamp_min/max have not > been recovered until user space screen on detection. The screen on response > would not be in time for the sensitive user when many background tasks are > running. Whether the kernel module could also > set sched_util_clamp_min/max? For boosting, are you just changing the sysctl or are you actively using sched_setattr() to boost tasks too? Please have a look at the documentation for the sysctl interface. https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tree/Documentation/admin-guide/sysctl/kernel.rst?h=sched/core#n1065 In summary, they just control the _allowed_ levels. So you can use it to cap/throttle the maximum performance level the system is running at. But you can't use it to boost the whole system. You must use the sched_setattr() to boost important tasks individually or if all the tasks are in a cgroup you can use that. For cgroup interface there's a caveat. If you want to use it let me know so I can explain how boosting would work there. I advise to use the sched_setattr() interface to target and boost those important tasks only. You can as well be smart and target all the background tasks to cap them via sched_setattr(). In this case you wouldn't have to modify the sysctl_sched_util_clamp_min/max. I don't see uclamp being a suitable interface for in-kernel users. PM_QOS is more suitable in my opinion for in-kernel users if you want to impact the overall system performance. I might have misunderstood what you were saying above. If so, can you please rephrase? Thanks -- Qais Yousef ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
