On Tue, May 10, 2016 at 10:10:21AM +0100, Morten Rasmussen wrote:
> > > > 2. If m < 32*64, the chance to be here is very very low, but if so,
> > >
> > > Should that be: n < 32*64 ?
Sorry, I overlooked this comment. Yes, it should be n < 32*64.
> > >
> > > Talking about 32*64, I don't get why
On Tue, May 10, 2016 at 10:10:21AM +0100, Morten Rasmussen wrote:
> > > > 2. If m < 32*64, the chance to be here is very very low, but if so,
> > >
> > > Should that be: n < 32*64 ?
Sorry, I overlooked this comment. Yes, it should be n < 32*64.
> > >
> > > Talking about 32*64, I don't get why
On Fri, May 06, 2016 at 02:19:32AM +0800, Yuyang Du wrote:
> Hi Morten,
>
> On Thu, May 05, 2016 at 12:13:10PM +0100, Morten Rasmussen wrote:
> > 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
On Fri, May 06, 2016 at 02:19:32AM +0800, Yuyang Du wrote:
> Hi Morten,
>
> On Thu, May 05, 2016 at 12:13:10PM +0100, Morten Rasmussen wrote:
> > 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
Hi Morten,
On Thu, May 05, 2016 at 12:13:10PM +0100, Morten Rasmussen wrote:
> 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.
> >
Hi Morten,
On Thu, May 05, 2016 at 12:13:10PM +0100, Morten Rasmussen wrote:
> 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.
> >
Hi Morten,
On 5 May 2016 at 13:13, Morten Rasmussen wrote:
> 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)
>>
Hi Morten,
On 5 May 2016 at 13:13, Morten Rasmussen wrote:
> 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,
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
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
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
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
12 matches
Mail list logo