Re: [PATCH v3 03/12] sched/fair: Change the variable to hold the number of periods to 32bit

[Morten Rasmussen]

On Wed, May 04, 2016 at 04:02:44AM +0800, Yuyang Du wrote:
> In sched average update, a period is about 1ms, so a 32-bit unsigned
> integer can approximately hold a maximum of 49 (=2^32/1000/3600/24)
> days.
> 
> For usual cases, 32bit is big enough and 64bit is needless. But if
> a task sleeps longer than it, there can be two outcomes:
> 
> Consider a task sleeps whatever m milliseconds, then n = (u32)m.

Maybe it crystal clear that you mean: For any m > UINT_MAX?

> 
> 1. If n >= 32*64, then the task's sched avgs will be surely decayed
>    to 0. In this case, it really doesn't matter that the 32bit is not
>    big enough to hold m. In other words, a task sleeps 2 secs or sleeps
>    50 days are the same from sched average point of view.
> 
> 2. If m < 32*64, the chance to be here is very very low, but if so,

Should that be: n < 32*64 ?

Talking about 32*64, I don't get why we don't use LOAD_AVG_MAX_N. I had
a patch ready to post for that: