From: Byungchul Park <byungchul.p...@lge.com>
hello,
there are 3 problems when att(det)aching a se to(from) its cfs_rq.
problem 1. se's average load is not accounted with new cfs_rq in queued case,
when a task changes its cgroup.
problem 2. cfs_rq->avg.load_avg becomes larger and larger whenever changing
cgroup to another. we have to sync se's average load with prev cfs_rq.
problem 3. current code does not sync it with its cfs_rq when switching
sched class to fair class. if we can always assume that a se has been
detached from fair class for a long time enough for its average load to
become useless, at the time attaching it to its fair class cfs_rq, then
current code is acceptable. but the assumption is not always true.
patch 1/5, does code refactoring for further patches.
patch 2/5, solves the problem 1.
patch 3/5, solves the problem 2.
patch 4/5, solves the problem 3.
patch 5/5, does code refactoring for better readability.
change from v2 to v1 (logic is not changed at all)
* fix up my poor english in commit message and comment
* break down big patches into more patches for being reviewed easily
* supplement cover letter messages
change from v1 to v2
* introduce two functions for adjusting vruntime and load when attaching
and detaching.
* call the introduced functions instead of switched_from(to)_fair() directly
in task_move_group_fair().
* add decaying logic for a se which has detached from a cfs_rq.
thanks,
byungchul
Byungchul Park (5):
sched: add two functions adjusting cfs_rq's load when att(det)aching
a se
sched: make task_move_group_fair adjust cfs_rq's load in case of
queued
sched: sync a se with prev cfs_rq when changing cgroup
sched: sync a se with its cfs_rq when switching sched class to fair
class
sched: add two functions for att(det)aching a task to(from) a cfs_rq
kernel/sched/fair.c | 209 +++++++++++++++++++++++++++------------------------
1 file changed, 110 insertions(+), 99 deletions(-)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
