aboutsummaryrefslogtreecommitdiffstats
path: root/kernel/sched_debug.c
diff options
context:
space:
mode:
authorRik van Riel <riel@redhat.com>2011-02-01 09:48:37 -0500
committerIngo Molnar <mingo@elte.hu>2011-02-03 14:20:32 +0100
commit2c13c919d9e9a3db9896143a501f83dcbbe1ced4 (patch)
tree4c326d2384ee0d09991cf5246baead5cfd08f3f9 /kernel/sched_debug.c
parentsched: Check the right ->nr_running in yield_task_fair() (diff)
downloadlinux-dev-2c13c919d9e9a3db9896143a501f83dcbbe1ced4.tar.xz
linux-dev-2c13c919d9e9a3db9896143a501f83dcbbe1ced4.zip
sched: Limit the scope of clear_buddies
The clear_buddies function does not seem to play well with the concept of hierarchical runqueues. In the following tree, task groups are represented by 'G', tasks by 'T', next by 'n' and last by 'l'. (nl) / \ G(nl) G / \ \ T(l) T(n) T This situation can arise when a task is woken up T(n), and the previously running task T(l) is marked last. When clear_buddies is called from either T(l) or T(n), the next and last buddies of the group G(nl) will be cleared. This is not the desired result, since we would like to be able to find the other type of buddy in many cases. This especially a worry when implementing yield_task_fair through the buddy system. The fix is simple: only clear the buddy type that the task itself is indicated to be. As an added bonus, we stop walking up the tree when the buddy has already been cleared or pointed elsewhere. Signed-off-by: Rik van Riel <riel@redhat.coM> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <20110201094837.6b0962a9@annuminas.surriel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'kernel/sched_debug.c')
0 files changed, 0 insertions, 0 deletions