Re: [PATCH 1/2] sched: Fix "divide error: 0000" in find_busiest_group

[Peter Zijlstra <peterz@infradead.org>]

On Tue, 2011-07-19 at 16:20 -0600, Terry Loftin wrote:
> On 07/19/2011 03:17 PM, Peter Zijlstra wrote:
> > On Tue, 2011-07-19 at 14:58 -0600, Terry Loftin wrote:
> >> Correct the protection expression in update_cpu_power() to avoid setting
> >> rq->cpu_power to zero.
> > 
> > Firstly you fail to mention what kernel this is again, secondly this
> > should never happen in the first place, so this fix is wrong. At best it
> > papers over another bug.
> 
> My Apologies, this was found on kernel 2.6.32.32, but the all
> the related code is the same in v3.0-rc7.  The patch is against
> v3.0-rc7.  I've done some limited testing of this on 2.6.32.32
> by modifying __cycles_2_ns() to add an offset to the TSC when
> it is read to simulate 208 days of uptime, but that kernel has
> only been running for a couple days.
> 
> I also agree this should never happen.  As the statement currently
> stands, it won't work - so it should either be corrected or removed.
> Here is the alternative patch:
> 

> -	if (!power)
> -		power = 1;

IIRC it can actually end up being 0 if the scale factors are small
enough, but what I couldn't see happening is how it can be > 2^32, which
is required for your initial patch to make a difference.

In that case the scale factors were _way_ out of bound, they're supposed
to be [0,SCHED_POWER_SCALE] and since we divide by SCHED_POWER_SCALE
after every factor the result should remain in that range.

Now clearly you've found that going haywire, so we need to find where
and why that happens and cure that.