Skip to contentSkip to conversation

Patch "sched/fair: Prevent throttling in early pick_next_task_fair()" has been added to the 4.1-stable tree

PATCH [email protected] 1 participant 1 message Oct 17, 2015

Subsystems (2)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

sched/fair: Prevent throttling in early pick_next_task_fair()

to the 4.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
sched-fair-prevent-throttling-in-early-pick_next_task_fair.patch
and it can be found in the queue-4.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From 54d27365cae88fbcc853b391dcd561e71acb81fa Mon Sep 17 00:00:00 2001

From: Ben Segall <[email protected]>
Date: Mon, 6 Apr 2015 15:28:10 -0700
Subject: sched/fair: Prevent throttling in early pick_next_task_fair()

From: Ben Segall <[email protected]>

commit 54d27365cae88fbcc853b391dcd561e71acb81fa upstream.

The optimized task selection logic optimistically selects a new task to run without first doing a full put_prev_task(). This is so that we can avoid a put/set on the common ancestors of the old and new task.

Similarly, we should only call check_cfs_rq_runtime() to throttle eligible groups if they're part of the common ancestry, otherwise it is possible to end up with no eligible task in the simple task selection.

Imagine:

		/root
	/prev		/next
	/A		/B

If our optimistic selection ends up throttling /next, we goto simple and our put_prev_task() ends up throttling /prev, after which we're going to bug out in set_next_entity() because there aren't any tasks left.

Avoid this scenario by only throttling common ancestors.

[ munged Changelog ]
Cc Andrew Morton <[email protected]>
Cc H. Peter Anvin <[email protected]>
Cc Linus Torvalds <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc Roman Gushchin <[email protected]>
Cc Thomas Gleixner <[email protected]>
Fixes 678d5718d8d0 ("sched/fair: Optimize cgroup pick_next_task_fair()")
---
 kernel/sched/fair.c |   25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)
kernel/sched/fair.c +14 -11
@@ -5126,18 +5126,21 @@ again:
 		 * entity, update_curr() will update its vruntime, otherwise
 		 * forget we've ever seen it.
 		 */
-		if (curr && curr->on_rq)
-			update_curr(cfs_rq);
-		else
-			curr = NULL;
+		if (curr) {
+			if (curr->on_rq)
+				update_curr(cfs_rq);
+			else
+				curr = NULL;
 
-		/*
-		 * This call to check_cfs_rq_runtime() will do the throttle and
-		 * dequeue its entity in the parent(s). Therefore the 'simple'
-		 * nr_running test will indeed be correct.
-		 */
-		if (unlikely(check_cfs_rq_runtime(cfs_rq)))
-			goto simple;
+			/*
+			 * This call to check_cfs_rq_runtime() will do the
+			 * throttle and dequeue its entity in the parent(s).
+			 * Therefore the 'simple' nr_running test will indeed
+			 * be correct.
+			 */
+			if (unlikely(check_cfs_rq_runtime(cfs_rq)))
+				goto simple;
+		}
 
 		se = pick_next_entity(cfs_rq, curr);
 		cfs_rq = group_cfs_rq(se);

Patches currently in stable-queue which might be from [email protected] are

queue-4.1/sched-fair-prevent-throttling-in-early-pick_next_task_fair.patch