Re: [PATCH] sched: Provide USF for the portable equipment.
On Thu, Jul 30, 2020 at 09:35:43PM +0800, Dongdong Yang wrote: > From: Dongdong Yang > > The power consumption and UI response are more cared > for by the portable equipment users. USF(User Sensitive > Feedback factor) auxiliary cpufreq governor is > providing more utils adjustment settings to a high > level by scenario identification. > > From the view of portable equipment, screen off status > usually stands for no request from the user, however, > the kernel is still expected to notify the user > in time on modem, network or powerkey events occur. > In some scenarios, such as listening to music, > low power processors, such as DSP, take more actions > and CPU load requirements cut down. It would bring > more power consumption benefit if high level have > interfaces to adjust utils according to the current > scenario and load. > > In addition, the portable equipment user usually heavy > interact with devices by touch, and other peripherals. > The boost preemptive counts are marking the load > requirement urgent, vice versa. If such feedback > factor could be set to high level according to the > scenario, it would contribute to the power consumption > and UI response. > > If no USF sysfs inode is set, and no screen on or > off event, adjust_task_pred_demand shall not be invoked. > Once sched_usf_up_l0_r/down_r/non_ux_r be set, > adjust_task_pred_demand_impl shall be called back > to update settings according to high level scenario > identification. > > We can get about 17% mean power consumption save > at listening to music with speaker on "screen > off" scenario, as below statistical data from 7766 > XiaoMi devices for two weeks with > sched_usf_non_ux_r be set: > > day1 day2 day3 day4 > count 7766.00 7766.00 7766.00 7766.00 > mean88.03552585.50028283.82930586.054997 > std 111.049980 108.258834 107.562583 108.558240 > min 0.099000 0.037000 0.067000 0.045000 > 25% 34.76550034.02175034.10150034.423000 > 50% 54.9555.28650054.18950054.248500 > 75% 95.95400093.94200091.73800094.0592500 > 80% 114.675000 107.43 106.378000 108.673000 > 85% 137.851000 129.511000 127.156500 131.750750 > 90% 179.669000 170.208500 164.027000 172.348000 > 95% 272.395000 257.845500 247.750500 263.275750 > 98% 399.034500 412.170400 391.484000 402.835600 > > day5 day6day7 day8 > count 7766.00 7766.0 7766.00 7766.00 > mean82.53267779.2192377.61138081.075081 > std 104.870079 101.34819 103.140037 97.506221 > min 0.051000 0.02900 0.007000 0.068000 > 25% 32.87300033.4440031.96550033.863500 > 50% 52.18050051.5655050.80650053.08 > 75% 90.90575086.8262583.85925089.973000 > 80% 105.455000 99.6470097.271000104.225000 > 85% 128.30 118.47825 116.570250 126.648250 > 90% 166.647500 149.18000 150.649500 161.087000 > 95% 247.208500 224.36050 226.38 245.291250 > 98% 393.002000 347.92060 369.791800 378.778600 > > day9 day10day11day12 > count 7766.00 7766.00 7766.00 7766.00 > mean79.98917083.85941778.03293077.060542 > std 104.226122 108.893043 102.561715 99.844276 > min 0.118000 0.017000 0.028000 0.039000 > 25% 32.05625033.45450031.17625030.897750 > 50% 51.50600054.05600048.96950049.069000 > 75% 88.51350092.95350083.50675084.096000 > 80% 102.876000 107.845000 97.71700098.073000 > 85% 124.363000 128.288000 118.366500 116.869250 > 90% 160.557000 167.084000 154.342500 148.187500 > 95% 231.149000 242.925750 236.759000 228.131250 > 98% 367.206600 388.619100 385.269100 376.541600 > > day13day14 > count 7766.00 7766.00 > mean75.52803673.702878 > std 90.75059486.796016 > min 0.066000 0.054000 > 25% 31.17050031.608500 > 50% 48.75850049.215000 > 75% 84.52275083.053000 > 80% 97.87900094.875000 > 85% 116.680250 113.573750 > 90% 149.083500 144.089500 > 95% 226.177750 211.488750 > 98% 347.011100 331.317100 > > Signed-off-by: Dongdong Yang > Signed-off-by: Jun Tao > Signed-off-by: Qiwu Huang > Signed-off-by: Geliang Tang > Signed-off-by: Peng Wang > --- > drivers/staging/Kconfig | 2 + > drivers/staging/Makefile | 1 + > drivers/staging/fbsched/Kconfig | 10 ++ > drivers/staging/fbsched/Makefile | 2 + > drivers/staging/fbsched/usf.c| 351 > +++ > kernel/sched/cpufreq_schedutil.c | 11 +- > 6 files changed, 376 insertions(+), 1 deletion(-) > create mode 100644
Re: [PATCH] sched: Provide USF for the portable equipment.
On Fri, 31 Jul 2020 20:15:38 +0200
pet...@infradead.org wrote:
> On Thu, Jul 30, 2020 at 09:35:43PM +0800, Dongdong Yang wrote:
> > diff --git a/kernel/sched/cpufreq_schedutil.c
> > b/kernel/sched/cpufreq_schedutil.c
> > index 7fbaee2..7bc3429 100644
> > --- a/kernel/sched/cpufreq_schedutil.c
> > +++ b/kernel/sched/cpufreq_schedutil.c
> > @@ -289,12 +289,21 @@ unsigned long schedutil_cpu_util(int cpu, unsigned
> > long util_cfs,
> > return min(max, util);
> > }
> >
> > +#ifdef CONFIG_SCHED_USF
> > +void (*adjust_task_pred_demand)(int cpuid, unsigned long *util,
> > + struct rq *rq) = NULL;
> > +EXPORT_SYMBOL(adjust_task_pred_demand);
> > +#endif
> > +
> > static unsigned long sugov_get_util(struct sugov_cpu *sg_cpu)
> > {
> > struct rq *rq = cpu_rq(sg_cpu->cpu);
> > unsigned long util = cpu_util_cfs(rq);
> > unsigned long max = arch_scale_cpu_capacity(sg_cpu->cpu);
> > -
> > +#ifdef CONFIG_SCHED_USF
> > + if (adjust_task_pred_demand)
> > + adjust_task_pred_demand(sg_cpu->cpu, , rq);
> > +#endif
> > sg_cpu->max = max;
> > sg_cpu->bw_dl = cpu_bw_dl(rq);
>
> NAK
Peter,
It's more informative if you include rational with a NAK.
-- Steve
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] sched: Provide USF for the portable equipment.
On Thu, Jul 30, 2020 at 09:35:43PM +0800, Dongdong Yang wrote:
> diff --git a/kernel/sched/cpufreq_schedutil.c
> b/kernel/sched/cpufreq_schedutil.c
> index 7fbaee2..7bc3429 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -289,12 +289,21 @@ unsigned long schedutil_cpu_util(int cpu, unsigned long
> util_cfs,
> return min(max, util);
> }
>
> +#ifdef CONFIG_SCHED_USF
> +void (*adjust_task_pred_demand)(int cpuid, unsigned long *util,
> + struct rq *rq) = NULL;
> +EXPORT_SYMBOL(adjust_task_pred_demand);
> +#endif
> +
> static unsigned long sugov_get_util(struct sugov_cpu *sg_cpu)
> {
> struct rq *rq = cpu_rq(sg_cpu->cpu);
> unsigned long util = cpu_util_cfs(rq);
> unsigned long max = arch_scale_cpu_capacity(sg_cpu->cpu);
> -
> +#ifdef CONFIG_SCHED_USF
> + if (adjust_task_pred_demand)
> + adjust_task_pred_demand(sg_cpu->cpu, , rq);
> +#endif
> sg_cpu->max = max;
> sg_cpu->bw_dl = cpu_bw_dl(rq);
NAK
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] sched: Provide USF for the portable equipment.
On Thu, Jul 30, 2020 at 09:35:43PM +0800, Dongdong Yang wrote: > From: Dongdong Yang > > The power consumption and UI response are more cared > for by the portable equipment users. USF(User Sensitive > Feedback factor) auxiliary cpufreq governor is > providing more utils adjustment settings to a high > level by scenario identification. > > >From the view of portable equipment, screen off status > usually stands for no request from the user, however, > the kernel is still expected to notify the user > in time on modem, network or powerkey events occur. > In some scenarios, such as listening to music, > low power processors, such as DSP, take more actions > and CPU load requirements cut down. It would bring > more power consumption benefit if high level have > interfaces to adjust utils according to the current > scenario and load. > > In addition, the portable equipment user usually heavy > interact with devices by touch, and other peripherals. > The boost preemptive counts are marking the load > requirement urgent, vice versa. If such feedback > factor could be set to high level according to the > scenario, it would contribute to the power consumption > and UI response. > > If no USF sysfs inode is set, and no screen on or > off event, adjust_task_pred_demand shall not be invoked. > Once sched_usf_up_l0_r/down_r/non_ux_r be set, > adjust_task_pred_demand_impl shall be called back > to update settings according to high level scenario > identification. > > We can get about 17% mean power consumption save > at listening to music with speaker on "screen > off" scenario, as below statistical data from 7766 > XiaoMi devices for two weeks with > sched_usf_non_ux_r be set: Nit, you can wrap your changelog text at 72 columns to make it easier to read. > > day1 day2 day3 day4 > count 7766.00 7766.00 7766.00 7766.00 > mean88.03552585.50028283.82930586.054997 > std 111.049980 108.258834 107.562583 108.558240 > min 0.099000 0.037000 0.067000 0.045000 > 25% 34.76550034.02175034.10150034.423000 > 50% 54.9555.28650054.18950054.248500 > 75% 95.95400093.94200091.73800094.0592500 > 80% 114.675000 107.43 106.378000 108.673000 > 85% 137.851000 129.511000 127.156500 131.750750 > 90% 179.669000 170.208500 164.027000 172.348000 > 95% 272.395000 257.845500 247.750500 263.275750 > 98% 399.034500 412.170400 391.484000 402.835600 > > day5 day6day7 day8 > count 7766.00 7766.0 7766.00 7766.00 > mean82.53267779.2192377.61138081.075081 > std 104.870079 101.34819 103.140037 97.506221 > min 0.051000 0.02900 0.007000 0.068000 > 25% 32.87300033.4440031.96550033.863500 > 50% 52.18050051.5655050.80650053.08 > 75% 90.90575086.8262583.85925089.973000 > 80% 105.455000 99.6470097.271000104.225000 > 85% 128.30 118.47825 116.570250 126.648250 > 90% 166.647500 149.18000 150.649500 161.087000 > 95% 247.208500 224.36050 226.38 245.291250 > 98% 393.002000 347.92060 369.791800 378.778600 > > day9 day10day11day12 > count 7766.00 7766.00 7766.00 7766.00 > mean79.98917083.85941778.03293077.060542 > std 104.226122 108.893043 102.561715 99.844276 > min 0.118000 0.017000 0.028000 0.039000 > 25% 32.05625033.45450031.17625030.897750 > 50% 51.50600054.05600048.96950049.069000 > 75% 88.51350092.95350083.50675084.096000 > 80% 102.876000 107.845000 97.71700098.073000 > 85% 124.363000 128.288000 118.366500 116.869250 > 90% 160.557000 167.084000 154.342500 148.187500 > 95% 231.149000 242.925750 236.759000 228.131250 > 98% 367.206600 388.619100 385.269100 376.541600 > > day13day14 > count 7766.00 7766.00 > mean75.52803673.702878 > std 90.75059486.796016 > min 0.066000 0.054000 > 25% 31.17050031.608500 > 50% 48.75850049.215000 > 75% 84.52275083.053000 > 80% 97.87900094.875000 > 85% 116.680250 113.573750 > 90% 149.083500 144.089500 > 95% 226.177750 211.488750 > 98% 347.011100 331.317100 > > Signed-off-by: Dongdong Yang > Signed-off-by: Jun Tao > Signed-off-by: Qiwu Huang > Signed-off-by: Geliang Tang > Signed-off-by: Peng Wang > --- > drivers/staging/Kconfig | 2 + > drivers/staging/Makefile | 1 + > drivers/staging/fbsched/Kconfig | 10 ++ > drivers/staging/fbsched/Makefile | 2 + > drivers/staging/fbsched/usf.c| 351 > +++ Why the different names, "fbsched" and "usf"? what does
Re: [PATCH] sched: Provide USF for the portable equipment.
On Thu, Jul 30, 2020 at 09:35:42PM +0800, Dongdong Yang wrote: > From: Dongdong Yang > > This patch provides USF(User Sensitive Feedback factor) > auxiliary cpufreq governor to support high level layer > sysfs inodes setting for utils adjustment purpose from > the identified scenario on portable equipment. > Because the power consumption and UI response are more > cared for by portable equipment users. And the "screen > off" status stands for no request from the user, however, > the kernel is still expected to notify the user in time > on modem, network or powerkey events occur. USF provides > "sched_usf_non_ux_r" sysfs inode to cut down the utils > from user space tasks according to high level scenario. > In addition, it usually hints more cpufreq demand that > the preemptive counts of the tasks on the cpu burst and > over the user expecting completed time such as the ratio > sysctl_sched_latency to sysctl_sched_min_granularity > on "screen on" status, which more likely with more UI. > The sysfs inodes "sched_usf_up_l0_r" and "sched_usf_down_r" > have been provided to adjust the utils according to high > level identified scenario to alloc the cpufreq in time. > > Dongdong Yang (1): > sched: Provide USF for portable equipment. > > drivers/staging/Kconfig | 2 + > drivers/staging/Makefile | 1 + > drivers/staging/fbsched/Kconfig | 10 ++ > drivers/staging/fbsched/Makefile | 2 + > drivers/staging/fbsched/usf.c| 351 > +++ > kernel/sched/cpufreq_schedutil.c | 11 +- > 6 files changed, 376 insertions(+), 1 deletion(-) > create mode 100644 drivers/staging/fbsched/Kconfig > create mode 100644 drivers/staging/fbsched/Makefile > create mode 100644 drivers/staging/fbsched/usf.c For new staging drivers/code, we need a TODO file that lists what remains to be done on the code to get it out of staging/ I don't see any good reason why this has to go to staging now, what prevents it from being merged to the "real" part of the kernel today? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] sched: Provide USF for the portable equipment.
On Thu, 30 Jul 2020 21:35:43 +0800
Dongdong Yang wrote:
I'll let others decide the value of this, but I have some comments.
>
> Signed-off-by: Dongdong Yang
> Signed-off-by: Jun Tao
> Signed-off-by: Qiwu Huang
> Signed-off-by: Geliang Tang
> Signed-off-by: Peng Wang
Why all the signed-off-bys? All of you worked on it?
> + if (evdata->data && val == FB_EVENT_BLANK) {
> + blank = *(int *)(evdata->data);
> +
> + switch (blank) {
> + case FB_BLANK_POWERDOWN:
> + usf_vdev.is_screen_on = 0;
> + if (usf_vdev.sysctl_sched_usf_non_ux != 0)
> + adjust_task_pred_demand =
> + _task_pred_demand_impl;
> + else
> + adjust_task_pred_demand = NULL;
So sysctl can enable and disable this?
> +
> + break;
> +
> diff --git a/kernel/sched/cpufreq_schedutil.c
> b/kernel/sched/cpufreq_schedutil.c
> index 7fbaee2..7bc3429 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -289,12 +289,21 @@ unsigned long schedutil_cpu_util(int cpu, unsigned long
> util_cfs,
> return min(max, util);
> }
>
> +#ifdef CONFIG_SCHED_USF
> +void (*adjust_task_pred_demand)(int cpuid, unsigned long *util,
> + struct rq *rq) = NULL;
> +EXPORT_SYMBOL(adjust_task_pred_demand);
> +#endif
> +
> static unsigned long sugov_get_util(struct sugov_cpu *sg_cpu)
> {
> struct rq *rq = cpu_rq(sg_cpu->cpu);
> unsigned long util = cpu_util_cfs(rq);
> unsigned long max = arch_scale_cpu_capacity(sg_cpu->cpu);
> -
> +#ifdef CONFIG_SCHED_USF
> + if (adjust_task_pred_demand)
> + adjust_task_pred_demand(sg_cpu->cpu, , rq);
The above is racy. Nothing stops adjust_task_pred_demand from being
non-null at the if condition, then becoming NULL before it is called.
Instead I would have the following:
DEFINE_STATIC_KEY_FALSE(adjust_task_pred_set);
#ifdef CONFIG_SCHED_USF
void adjust_task_pred_demand(int cpuid, unsigned long *util,
struct rq *rq);
#else
static inline void adjust_task_pred_demand(int cpuid,
unsigned long *util, struct rq *rq)
{ }
#endif
if (static_key_unlikely(adjust_task_pred_set))
adjust_task_pred_demand(sg_cpu->cpu, , rq);
And hopefully the compiler will just remove all of it if it's not
enabled.
Then you set the static branch when you want it to be called, and do
not use a racy function pointer.
-- Steve
> +#endif
> sg_cpu->max = max;
> sg_cpu->bw_dl = cpu_bw_dl(rq);
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] sched: Provide USF for the portable equipment.
From: Dongdong Yang The power consumption and UI response are more cared for by the portable equipment users. USF(User Sensitive Feedback factor) auxiliary cpufreq governor is providing more utils adjustment settings to a high level by scenario identification. From the view of portable equipment, screen off status usually stands for no request from the user, however, the kernel is still expected to notify the user in time on modem, network or powerkey events occur. In some scenarios, such as listening to music, low power processors, such as DSP, take more actions and CPU load requirements cut down. It would bring more power consumption benefit if high level have interfaces to adjust utils according to the current scenario and load. In addition, the portable equipment user usually heavy interact with devices by touch, and other peripherals. The boost preemptive counts are marking the load requirement urgent, vice versa. If such feedback factor could be set to high level according to the scenario, it would contribute to the power consumption and UI response. If no USF sysfs inode is set, and no screen on or off event, adjust_task_pred_demand shall not be invoked. Once sched_usf_up_l0_r/down_r/non_ux_r be set, adjust_task_pred_demand_impl shall be called back to update settings according to high level scenario identification. We can get about 17% mean power consumption save at listening to music with speaker on "screen off" scenario, as below statistical data from 7766 XiaoMi devices for two weeks with sched_usf_non_ux_r be set: day1 day2 day3 day4 count 7766.00 7766.00 7766.00 7766.00 mean88.03552585.50028283.82930586.054997 std 111.049980 108.258834 107.562583 108.558240 min 0.099000 0.037000 0.067000 0.045000 25% 34.76550034.02175034.10150034.423000 50% 54.9555.28650054.18950054.248500 75% 95.95400093.94200091.73800094.0592500 80% 114.675000 107.43 106.378000 108.673000 85% 137.851000 129.511000 127.156500 131.750750 90% 179.669000 170.208500 164.027000 172.348000 95% 272.395000 257.845500 247.750500 263.275750 98% 399.034500 412.170400 391.484000 402.835600 day5 day6day7 day8 count 7766.00 7766.0 7766.00 7766.00 mean82.53267779.2192377.61138081.075081 std 104.870079 101.34819 103.140037 97.506221 min 0.051000 0.02900 0.007000 0.068000 25% 32.87300033.4440031.96550033.863500 50% 52.18050051.5655050.80650053.08 75% 90.90575086.8262583.85925089.973000 80% 105.455000 99.6470097.271000104.225000 85% 128.30 118.47825 116.570250 126.648250 90% 166.647500 149.18000 150.649500 161.087000 95% 247.208500 224.36050 226.38 245.291250 98% 393.002000 347.92060 369.791800 378.778600 day9 day10day11day12 count 7766.00 7766.00 7766.00 7766.00 mean79.98917083.85941778.03293077.060542 std 104.226122 108.893043 102.561715 99.844276 min 0.118000 0.017000 0.028000 0.039000 25% 32.05625033.45450031.17625030.897750 50% 51.50600054.05600048.96950049.069000 75% 88.51350092.95350083.50675084.096000 80% 102.876000 107.845000 97.71700098.073000 85% 124.363000 128.288000 118.366500 116.869250 90% 160.557000 167.084000 154.342500 148.187500 95% 231.149000 242.925750 236.759000 228.131250 98% 367.206600 388.619100 385.269100 376.541600 day13day14 count 7766.00 7766.00 mean75.52803673.702878 std 90.75059486.796016 min 0.066000 0.054000 25% 31.17050031.608500 50% 48.75850049.215000 75% 84.52275083.053000 80% 97.87900094.875000 85% 116.680250 113.573750 90% 149.083500 144.089500 95% 226.177750 211.488750 98% 347.011100 331.317100 Signed-off-by: Dongdong Yang Signed-off-by: Jun Tao Signed-off-by: Qiwu Huang Signed-off-by: Geliang Tang Signed-off-by: Peng Wang --- drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + drivers/staging/fbsched/Kconfig | 10 ++ drivers/staging/fbsched/Makefile | 2 + drivers/staging/fbsched/usf.c| 351 +++ kernel/sched/cpufreq_schedutil.c | 11 +- 6 files changed, 376 insertions(+), 1 deletion(-) create mode 100644 drivers/staging/fbsched/Kconfig create mode 100644 drivers/staging/fbsched/Makefile create mode 100644 drivers/staging/fbsched/usf.c diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index 4ec5528..05b231e 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -120,4 +120,6 @@
[PATCH] sched: Provide USF for the portable equipment.
From: Dongdong Yang This patch provides USF(User Sensitive Feedback factor) auxiliary cpufreq governor to support high level layer sysfs inodes setting for utils adjustment purpose from the identified scenario on portable equipment. Because the power consumption and UI response are more cared for by portable equipment users. And the "screen off" status stands for no request from the user, however, the kernel is still expected to notify the user in time on modem, network or powerkey events occur. USF provides "sched_usf_non_ux_r" sysfs inode to cut down the utils from user space tasks according to high level scenario. In addition, it usually hints more cpufreq demand that the preemptive counts of the tasks on the cpu burst and over the user expecting completed time such as the ratio sysctl_sched_latency to sysctl_sched_min_granularity on "screen on" status, which more likely with more UI. The sysfs inodes "sched_usf_up_l0_r" and "sched_usf_down_r" have been provided to adjust the utils according to high level identified scenario to alloc the cpufreq in time. Dongdong Yang (1): sched: Provide USF for portable equipment. drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + drivers/staging/fbsched/Kconfig | 10 ++ drivers/staging/fbsched/Makefile | 2 + drivers/staging/fbsched/usf.c| 351 +++ kernel/sched/cpufreq_schedutil.c | 11 +- 6 files changed, 376 insertions(+), 1 deletion(-) create mode 100644 drivers/staging/fbsched/Kconfig create mode 100644 drivers/staging/fbsched/Makefile create mode 100644 drivers/staging/fbsched/usf.c -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
