中心，调度程序驱动的，功率性能控制
（实验性）
抽象
========
过去，在多个场合[1,2]都提出了一个简单的功率性能可调参数，该参数完全以调度程序为中心，并具有定义明确和可预测的属性。 借助诸如调度程序驱动的DVFS [3]之类的技术，我们现在有了一个实现这种可调参数的良好框架。 本文档描述了其设计和实现背后的总体思路。
目录
=================
1.动机
2.简介
3.信号增强(Signal Boosting)策略
4.通过boosted CPU利用率选择OPP
5.每个任务组的boosting
6.问题与答案
-什么是“auto”模式呢？
-在拥塞的系统上如何boosting？
-当我们有多个boost值的任务时，如何boost CPU？
7.参考
1.动机
=============
Sched-DVFS [3]是一种新的事件驱动的cpufreq调控器，它允许调度程序选择最佳DVFS操作点（OPP）来运行分配给CPU的任务。sched-DVFS的引入使工作负载能够以最节能的OPP运行。
但是，有时可能希望有意提高一个工作负载的性能，即使这可能意味着合理的增加能耗。 例如，为了减少任务的响应时间，我们可能希望以高于CPU带宽实际需求要求的OPP来运行该任务。
如果我们认为sched-DVFS组件的主要目标之一是替换所有当前可用的CPUFreq策略，则最后一个要求尤其重要。 由于sched-DVFS是基于事件的，与我们目前拥有的采样驱动调速器相反，它在选择最佳OPP来运行分配给CPU的任务方面已经具有更快的响应能力。 但是，从性能的角度来看，仅跟踪实际任务负载需求可能还不够。 例如，不可能获得与“性能”和“交互式” CPUFreq调控器提供的行为类似的行为。
本文档介绍了在sched-DVFS顶部堆叠的可调参数的实现，该参数扩展了其功能以支持任务性能的提升(boosting)。
“提高性能”是指减少完成任务激活所需的时间，即从任务唤醒到下一次停用所花费的时间（例如，因为它返回睡眠状态或终止）。 例如，如果我们考虑一个简单的周期性任务，该任务以某个OPP运行时周期20[s]，每5[s]执行一次相同的工作负载，则该任务的增强执行必须在少于5[s]的时间内完成其每次激活。
引入这种增强功能的先前尝试[5]尚未成功，主要是因为所提出的解决方案很复杂。 本文档中描述的方法向用户空间导出了一个简单的接口。 这个单一的可调旋钮允许调节系统范围的调度程序行为，范围从一端的能源效率到另一端的性能提升。 此第一个可调参数会影响所有任务。 但是，还提供了该概念的更高级扩展，该概念使用CGroups来提高仅选定任务的性能，同时对所有其他任务使用节能默认值。
本文档的其余部分将更详细地介绍已提议的解决方案，该解决方案名为SchedTune。
2.简介
===============
SchedTune公开了具有单个功率性能可调参数的简单用户空间接口：
/proc/sys/kernel/sched_cfs_boost //4.19没使能CONFIG_SCHED_TUNE，Qcom有自己的sched_boost。
/sys # find ./ -name "*boost*" //可以看到系统诸多boost相关实现文件
这允许将提升值表示为[0..100]范围内的整数。注释：Qcom的sched_boost只允许写1或0
值0（默认）配置CFS调度程序以实现最大的能源效率。 这意味着sched-DVFS以满足其工作负载需求所需的最低OPP运行任务。值为100时，将配置调度程序以实现最高性能，这将转换为该CPU上最大OPP的选择。
可以设置0到100之间的范围以适合其他情况。 例如，为了满足交互式响应或取决于其他系统事件（电池电量等）。
还提供了基于CGroup的扩展，它允许进一步的将用户空间定义的任务分类，以根据任务的特定性质（例如任务）为不同目标调整调度程序。 后台、交互、低优先级。
通过在操作性能点（OPP）选择上引入偏差，SchedTune模块的总体设计基于“每实体负载跟踪”（PELT）信号和sched-DVFS之上。每次在CPU上分配任务时，sched-DVFS都有机会调整该CPU的工作频率以更好地满足工作负载需求。 激活的实际OPP的选择受全局提升值或使用中任务CGroup的提升值的影响。
这种简单的偏置方法利用了现有的框架，这意味着对调度程序的修改最少，但是它允许通过单个简单的可调旋钮实现一系列不同的行为。 引入的唯一新概念是信号增强的概念。
3.信号增强策略
==========================
整个PELT机器都基于一些负载跟踪信号的值来工作，这些信号基本上跟踪任务的CPU带宽要求和CPU的算力。 SchedTune旋钮背后的基本思想是人为地增加这些负载跟踪信号中的一部分，以使任务或RQ看起来比实际更需要算力。
哪些信号必须充气取决于特定的“消费者”。 但是，独立于特定的（信号，消费者）对，为增强信号的概念定义简单且可能一致的策略很重要。
提升策略定义如何将“抽象”用户空间定义的 sched_cfs_boost 值转换为内部“margin”值，以将其添加到信号中以获得其膨胀值：
margin := boosting_strategy(sched_cfs_boost, signal)
boosted_signal := signal + margin
在选择最有效的策略之前，先确定并分析了不同的策略。
信号比例补偿（SPC）
--------------------------------------
在这种增强策略中，sched_cfs_boost值用于计算与原始信号的补码成比例的余量。 当信号具有最大可能值时，其补码定义为实际值与其可能最大值的差值。
由于可调实施使用的信号具有 SCHED_LOAD_SCALE 作为最大可能值，因此裕度变为：
margin := sched_cfs_boost * (SCHED_LOAD_SCALE - signal)
使用这种提升策略：
- 100% sched_cfs_boost 表示信号被缩放到最大值
- sched_cfs_boost 范围内的每个值均以与最大值成比例的数量有效地使所讨论的信号膨胀。
例如，通过将SPC提升策略应用于OPP的选择以运行任务，可以实现以下行为：
- 提高0%：以工作负载所需的最低OPP运行任务
- 100%提升：以CPU可用的最大OPP运行任务
- 50%：在最低和最高之间的中间OPP运行
这意味着，以50%的速度boosting时，将计划在特定目标平台上以理论上可达到的最大性能一半的速度运行任务。
下图显示了SPC增强信号的图形表示，其中：
a）“-”代表原始信号
b）“b”代表增强信号50％
c）“p”代表100％增强信号
^ | SCHED_LOAD_SCALE +-----------------------------------------------------------------+ |pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp | | boosted_signal | bbbbbbbbbbbbbbbbbbbbbbbb | | original signal | bbbbbbbbbbbbbbbbbbbbbbbb+----------------------+ | | |bbbbbbbbbbbbbbbbbb | | | | | | | | +-----------------------+ | | | | | | |------------------+ | | +----------------------------------------------------------------------->
上图显示了一个倾斜的负载信号（标题为“ original_signal”），并且其提升了等效值。 对于原始信号的每一步，对应于50％增强的增强信号位于原始信号和上限之间的中间位置。 100％增强会生成增强信号，该信号始终饱和到上限。
4.通过提高CPU利用率选择OPP
=============================================
值得一提的是，该实现不会引入任何新的负载信号。 相反，它提供了一个API以调整现有信号。 这种调整是按需完成的，并且仅在明智的调度程序代码路径中进行。 定义新的API调用以返回默认信号或增强信号，具体取决于 sched_cfs_boost 的值。 这是对现有现有代码路径的干净无创的修改。
根据先前描述的SPC提升策略，提升代表CPU利用率的信号。 对于sched-DVFS，这使CPU（即CFS运行队列）看起来比实际使用的更多。
因此，启用 sched_cfs_boost 后，我们具有以下主要功能来获取CPU的当前利用率：
cpu_util()
boosted_cpu_util()
新的 boosted_cpu_util()与 cpu_util()类似，但返回的是boosted后的利用率信号，该信号是sched_cfs_boost值的函数。
此功能用于CFS调度程序代码路径中，其中sched-DVFS需要确定运行CPU的OPP。 例如，这允许为boost值设置为100%的CPU选择最高的OPP。
5.每个任务组的boosting
=========================
用于增强系统中所有任务的单个旋钮的可用性无疑是一个简单的解决方案，但很可能不适合许多使用情况，尤其是在移动设备领域。
例如，在电池供电的设备上，通常有许多后台服务，这些后台服务运行时间长且需要节能调度。 另一方面，某些应用程序对性能更敏感，并且无论能耗如何，都需要交互式响应和/或最佳性能。 为了更好地服务于此类情况，SchedTune实现具有扩展功能，可提供更细粒度的增强接口。
可以启用一个新的CGroup控制器，即“ schedtune”，该控制器允许使用不同的提升值来定义和配置任务组。 需要特殊性能的任务可以放入单独的CGroup中。 可以使用CGroup控制器暴露的单个旋钮来指定与此组中的任务相关联的boost的值：
schedtune.boost
//PS：Qcom平台 /dev/stune # find ./ -name schedtune.boost ./foreground/schedtune.boost ./rt/schedtune.boost ./audio-app/schedtune.boost ./top-app/schedtune.boost ./background/schedtune.boost ./schedtune.boost
该旋钮允许定义一个提升值，该值将用于对该组中所有任务的SPC提升。
当前的schedtune控制器实现非常简单，并具有以下主要特征：
1）只能创建1级深度层次
根控制组定义了默认情况下将应用于所有任务的系统范围的提升值。 它的直接子组称为“boost groups”，它们为特定任务集定义提升值。不允许使用其他嵌套子组，因为从用户空间的角度来看，它们没有有意义的含义。
2）可以仅定义有限数量的“boost groups”
此数字是在编译时定义的，默认情况下配置为16。这是出于两个主要原因的设计决策：
a）在真实的系统中，我们不希望使用过多的提升组利用率方案。 例如，合理的组集合可以只是“background”，“interactive”和“performance”。
b）大大简化了实现，尤其是对于存在多个具有不同提升值的RUNNABLE任务时必须计算每个CPU提升的代码。
这种简单的设计应该可以为迄今为止确定的主要使用方案提供服务。 它提供了一个简单的接口，可用于管理所有任务或仅选定任务的性能。 此外，该接口可以很容易地与用户空间运行时（例如Android，ChromeOS）集成在一起，以实现基于任务分类的用于任务提升的QoS解决方案，这是长期以来的要求。
设置和使用
---------------
0.使用启用了 CGROUP_SCHEDTUNE 支持的内核
1.检查“ schedtune” CGroup控制器是否可用：
root@linaro-nano:~# cat /proc/cgroups #subsys_name hierarchy num_cgroups enabled cpuset 0 1 1 cpu 0 1 1 schedtune 0 1 1
2.挂载tmpfs以创建CGroups挂载点（可选）
root@linaro-nano:~# sudo mount -t tmpfs cgroups /sys/fs/cgroup
3.安装“ schedtune”控制器
root@linaro-nano:~# mkdir /sys/fs/cgroup/stune
root@linaro-nano:~# sudo mount -t cgroup -o schedtune stune /sys/fs/cgroup/stune
4.设置系统范围的提升值（可选）
如果未配置，则根控制组的提升值为0％，该值基本上禁用了系统中所有任务的提升，因此以节能模式运行。
root@linaro-nano:~# echo $SYSBOOST > /sys/fs/cgroup/stune/schedtune.boost
5.创建任务组并配置其特定的提升值（可选）
例如，在这里我们创建一个“性能”提升组配置，以将其所有任务提升到100％
root@linaro-nano:~# mkdir /sys/fs/cgroup/stune/performance root@linaro-nano:~# echo 100 > /sys/fs/cgroup/stune/performance/schedtune.boost
6.将任务移入Boost组
例如，以下内容将PID为$TASKPID的任务（及其所有线程）移入“performance”提升组。
root@linaro-nano:~# echo "TASKPID > /sys/fs/cgroup/stune/performance/cgroup.procs
这种简单的配置只允许$TASKPID任务的线程在需要时以系统功能最强大的CPU中最高的OPP运行。
6.问题与答案
=======================
那“auto”模式呢？
-----------------------
可以通过将SchedTune与某些合适的用户空间元素接口来实现[5]中所述的“自动”模式。 该元素可以使用公开的系统范围或基于cgroup的接口。
如何管理具有不同提升值的多组任务？
-------------------------------------------------- -------------------
当前的SchedTune实现跟踪在CPU上增强的RUNNABLE任务。 一旦sched-DVFS选择运行CPU的OPP，将以其RQ中当前RUNNABLE任务的提升值的最大值来提升CPU利用率。这使得sched-DVFS仅在有增强任务准备运行时才增强CPU，并在最后一个增强任务出队后立即切换回节能模式。
7. 参考
=============
[1] http://lwn.net/Articles/552889
[2] http://lkml.org/lkml/2012/5/18/91
[3] http://lkml.org/lkml/2015/6/26/620
--------------------------------------------------------------------------------------------------------------------------------------
TODO:
/dev/stune # ls -l total 0 drwxr-xr-x 2 system system 0 1970-01-29 08:50 audio-app drwxr-xr-x 2 system system 0 1970-01-29 08:50 background -rw-r--r-- 1 root root 0 2021-02-03 02:01 cgroup.clone_children -rw-r--r-- 1 root root 0 2021-02-03 02:12 cgroup.procs -r--r--r-- 1 root root 0 2021-02-03 02:12 cgroup.sane_behavior drwxr-xr-x 2 system system 0 1970-01-29 08:50 foreground -rw-r--r-- 1 root root 0 2021-02-03 02:12 notify_on_release -rw-r--r-- 1 root root 0 2021-02-03 02:12 release_agent drwxr-xr-x 2 system system 0 1970-01-29 08:50 rt -rw-r--r-- 1 root root 0 2021-02-03 01:35 schedtune.boost -rw-r--r-- 1 root root 0 1970-01-29 08:50 schedtune.colocate -rw-r--r-- 1 root root 0 2021-02-03 02:12 schedtune.prefer_idle -rw-r--r-- 1 root root 0 2021-02-03 02:12 schedtune.sched_boost_no_override -rw-rw-r-- 1 root system 0 2021-01-22 21:31 schedtune.window_policy -rw-rw-r-- 1 system system 0 1970-01-29 08:50 tasks drwxr-xr-x 2 system system 0 1970-01-29 08:50 top-app /dev/stune/top-app # ls -l total 0 -rw-r--r-- 1 root root 0 2021-02-03 02:12 cgroup.clone_children -rw-r--r-- 1 root root 0 2021-02-03 02:12 cgroup.procs -rw-r--r-- 1 root root 0 2021-02-03 02:12 notify_on_release -rw-rw-r-- 1 system system 0 2021-02-03 01:36 schedtune.boost -rw-rw-r-- 1 root root 0 1970-01-29 08:50 schedtune.colocate -rw-r--r-- 1 root root 0 2021-02-03 02:12 schedtune.prefer_idle -rw-r--r-- 1 root root 0 1970-01-29 08:50 schedtune.sched_boost_no_override -rw-rw-r-- 1 root system 0 2021-01-22 21:31 schedtune.window_policy -rw-rw-r-- 1 system system 0 1970-01-29 08:50 tasks
schedtune.colocate、schedtune.prefer_idle 等待说明