Re: [PATCH v3 03/12] sched/fair: Change the variable to hold the number of periods to 32bit
From: Morten Rasmussen
Date: Thu May 05 2016 - 07:12:59 EST
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)
> 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: