Date: Fri, 29 Apr 2016 02:33:47 +0800
From: Yuyang Du <yuyang.du@intel.com>
To: bsegall@google.com
Cc: peterz@infradead.org, mingo@kernel.org, linux-kernel@vger.kernel.org,
        pjt@google.com, morten.rasmussen@arm.com, vincent.guittot@linaro.org,
        dietmar.eggemann@arm.com, juri.lelli@arm.com
Subject: Re: [PATCH 3/6] sched/fair: Change the variable to hold the number
 of periods to 32bit integer
Message-ID: <20160428183347.GB16093@intel.com>
References: <1461812173-32439-1-git-send-email-yuyang.du@intel.com>
 <1461812173-32439-4-git-send-email-yuyang.du@intel.com>
 <xm26vb317ib0.fsf@bsegall-linux.mtv.corp.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <xm26vb317ib0.fsf@bsegall-linux.mtv.corp.google.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 626
Lines: 13

On Thu, Apr 28, 2016 at 10:29:55AM -0700, bsegall@google.com wrote:
> Yuyang Du <yuyang.du@intel.com> writes:
> 
> > Now a period is about 1ms, so a 32-bit unsigned integer can approximately
> > hold a maximum of 49 (=2^32/1000/3600/24) days, which means it is big enough
> > and 64-bit is needless.
> >
> If a thread sleeps for 49 days and then wakes up this would be wrong...
> but it also would just result in it not being decayed to zero, and even
> then only if it was in a very small window, so it doesn't seem like a
> huge deal if it happens.
 
Oh, yeah, and we wouldn't know that task is as sleepy as it realy is. :)