summaryrefslogtreecommitdiffstats
path: root/kernel/sched/fair.c
diff options
context:
space:
mode:
authorPeter Zijlstra <peterz@infradead.org>2016-12-21 09:05:02 +0100
committerIngo Molnar <mingo@kernel.org>2017-01-14 11:30:01 +0100
commitda9647e076d440190fff4b4ee0f4b829dd6e8c4f (patch)
tree7bedc99c5a41500084b0ef26673cb64ab751de0e /kernel/sched/fair.c
parent59f8c2989283bbd3df9fcfb22494d84f4852e536 (diff)
downloadop-kernel-dev-da9647e076d440190fff4b4ee0f4b829dd6e8c4f.zip
op-kernel-dev-da9647e076d440190fff4b4ee0f4b829dd6e8c4f.tar.gz
sched/completions: Fix complete_all() semantics
Documentation/scheduler/completion.txt says this about complete_all(): "calls complete_all() to signal all current and future waiters." Which doesn't strictly match the current semantics. Currently complete_all() is equivalent to UINT_MAX/2 complete() invocations, which is distinctly less than 'all current and future waiters' (enumerable vs innumerable), although it has worked in practice. However, Dmitry had a weird case where it might matter, so change completions to use saturation semantics for complete()/complete_all(). Once done hits UINT_MAX (and complete_all() sets it there) it will never again be decremented. Requested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: der.herr@hofr.at Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'kernel/sched/fair.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud