Ensure that the move of a sched_entity will be reflected in load and
utilization of the task_group hierarchy.
When a sched_entity moves between groups or CPUs, load and utilization
of cfs_rq don't reflect the changes immediately but converge to new values.
As a result, the metrics are no more aligned with the new balance of the
load in the system and next decisions will have a biased view.
This patchset synchronizes load/utilization of sched_entity with its child
cfs_rq (se->my-q) only when tasks move to/from child cfs_rq:
-move between task group
-migration between CPUs
Otherwise, PELT is updated as usual.
Changes since v2:
- Propagate both utilization and load
- Synced sched_entity and se->my_q instead of adding the delta
Changes since v1:
- This patch needs the patch that fixes issue with rq->leaf_cfs_rq_list
"sched: fix hierarchical order in rq->leaf_cfs_rq_list" in order to work
correctly. I haven't sent them as a single patchset because the fix is
independent of this one
- Merge some functions that are always used together
- During update of blocked load, ensure that the sched_entity is synced
with the cfs_rq applying changes
- Fix an issue when task changes its cpu affinity
Vincent Guittot (7):
sched: factorize attach entity
sched: fix hierarchical order in rq->leaf_cfs_rq_list
sched: factorize PELT update
sched: propagate load during synchronous attach/detach
sched: propagate asynchrous detach
sched: fix task group initialization
sched: fix wrong utilization accounting when switching to fair class
kernel/sched/core.c | 21 ++--
kernel/sched/fair.c | 319 ++++++++++++++++++++++++++++++++++++++++-----------
kernel/sched/sched.h | 2 +
3 files changed, 264 insertions(+), 78 deletions(-)
--
1.9.1
Tree/Branch: v4.7.5
Git describe: v4.7.5
Commit: 6c21842b5f Linux 4.7.5
Build Time: 71 min 4 sec
Passed: 9 / 9 (100.00 %)
Failed: 0 / 9 ( 0.00 %)
Errors: 0
Warnings: 2
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
2 warnings 0 mismatches : arm64-allmodconfig
1 warnings 0 mismatches : x86_64-defconfig
1 warnings 0 mismatches : arm-multi_v7_defconfig
1 warnings 0 mismatches : arm-allmodconfig
1 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 2
5 ../fs/nfs/nfs4session.c:201:54: warning: 'cur_seq' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../fs/reiserfs/ibalance.c:1156:2: warning: 'new_insert_key' may be used uninitialized in this function [-Wmaybe-uninitialized]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../fs/nfs/nfs4session.c:201:54: warning: 'cur_seq' may be used uninitialized in this function [-Wmaybe-uninitialized]
../fs/reiserfs/ibalance.c:1156:2: warning: 'new_insert_key' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../fs/nfs/nfs4session.c:201:54: warning: 'cur_seq' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../fs/nfs/nfs4session.c:201:54: warning: 'cur_seq' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../fs/nfs/nfs4session.c:201:54: warning: 'cur_seq' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../fs/nfs/nfs4session.c:201:54: warning: 'cur_seq' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
x86_64-allnoconfig
arm64-allnoconfig
arm-allnoconfig
arm-multi_v5_defconfig
It was never compulsory to have a compatible string in the OPP table.
Fix the documentation to mark it optional.
Also update its description a bit.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
Documentation/devicetree/bindings/opp/opp.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index ee91cbdd95ee..5eab6f0215d1 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -55,14 +55,14 @@ This describes the OPPs belonging to a device. This node can have following
properties:
Required properties:
-- compatible: Allow OPPs to express their compatibility. It should be:
- "operating-points-v2".
-
- OPP nodes: One or more OPP nodes describing voltage-current-frequency
combinations. Their name isn't significant but their phandle can be used to
reference an OPP.
Optional properties:
+- compatible: Allow OPPs to express their compatibility. It should be
+ "operating-points-v2" or a vendor specific string.
+
- opp-shared: Indicates that device nodes using this OPP Table Node's phandle
switch their DVFS state together, i.e. they share clock/voltage/current lines.
Missing property means devices have independent clock/voltage/current lines,
--
2.7.1.410.g6faf27b