sched: Fix and optimise calculation of the weight-inverse

Commit-ID:  db670dac49b5423b39b5e523d28fe32045d71b10
Gitweb:     http://git.kernel.org/tip/db670dac49b5423b39b5e523d28fe32045d71b10
Author:     Stephan Baerwolf <[email protected]>
AuthorDate: Wed, 11 May 2011 18:03:29 +0200
Committer:  Ingo Molnar <[email protected]>
CommitDate: Mon, 16 May 2011 11:01:18 +0200

sched: Fix and optimise calculation of the weight-inverse

If the inverse loadweight should be zero, function "calc_delta_mine" calculates the inverse of "lw->weight" (in 32bit integer ops).

This calculation is actually a little bit impure (because it is inverting something around "lw-weight"+1), especially when "lw->weight" becomes smaller.

The correct inverse would be 1/lw->weight multiplied by "WMULT_CONST" for fixcomma-scaling it into integers. (So WMULT_CONST/lw->weight ...)

The old, impure algorithm took two divisions for inverting lw->weight, the new, more exact one only takes one and an additional unlikely-if.

[ This could explain some aritmetical issues for small shares but nothing
concrete has been reported yet so we are not confident enough to queue this up in sched/urgent and for -stable backport. But if anyone finds this commit and sees it to fix some badness then we can certainly change our mind! ]

---
 kernel/sched.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

index 70bec4f..c62acf4 100644
@@ -1330,15 +1330,15 @@ calc_delta_mine(unsigned long delta_exec, unsigned long weight,
 {
 	u64 tmp;
 
+	tmp = (u64)delta_exec * weight;
+
 	if (!lw->inv_weight) {
 		if (BITS_PER_LONG > 32 && unlikely(lw->weight >= WMULT_CONST))
 			lw->inv_weight = 1;
 		else
-			lw->inv_weight = 1 + (WMULT_CONST-lw->weight/2)
-				/ (lw->weight+1);
+			lw->inv_weight = WMULT_CONST / lw->weight;
 	}
 
-	tmp = (u64)delta_exec * weight;
 	/*
 	 * Check whether we'd overflow the 64-bit multiplication:
 	 */

Just want to highlight this aspect of Stephan's scheduler fix for the lkml discussion:

So this could be a -stable candidate because it's a fix and it's simple, except that at the moment we have no reason to believe that this is a regression or a serious bug.

Thanks,

Ingo