On 16 June 2016 at 01:24, Yuyang Du wrote:
> On Thu, Jun 16, 2016 at 09:12:58AM +0200, Vincent Guittot wrote:
>> > Then, when enqueued, both cfs_rq and task will be decayed to 0, due to
>> > a large gap between 1 and now, no?
>>
>> yes, like it is done currently (but 1ns later) .
>
> Well, current
On Thu, Jun 16, 2016 at 09:12:58AM +0200, Vincent Guittot wrote:
> > Then, when enqueued, both cfs_rq and task will be decayed to 0, due to
> > a large gap between 1 and now, no?
>
> yes, like it is done currently (but 1ns later) .
Well, currently, cfs_rq will be decayed to 0, but will then add t
On 15 June 2016 at 21:19, Yuyang Du wrote:
> On Mon, May 30, 2016 at 05:52:20PM +0200, Vincent Guittot wrote:
>> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
>> that the 1st sched_entity that will be attached, will keep its
>> last_update_time set to 0 and will attached
On Mon, May 30, 2016 at 05:52:20PM +0200, Vincent Guittot wrote:
> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
> that the 1st sched_entity that will be attached, will keep its
> last_update_time set to 0 and will attached once again during the
> enqueue.
> Initialize cf
Hi Dietmar,
On 6 June 2016 at 21:32, Dietmar Eggemann wrote:
> On 01/06/16 16:54, Vincent Guittot wrote:
>> On 1 June 2016 at 17:31, Dietmar Eggemann wrote:
>>> On 30/05/16 16:52, Vincent Guittot wrote:
The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
that the 1
On 01/06/16 16:54, Vincent Guittot wrote:
> On 1 June 2016 at 17:31, Dietmar Eggemann wrote:
>> On 30/05/16 16:52, Vincent Guittot wrote:
>>> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
>>> that the 1st sched_entity that will be attached, will keep its
>>
>> attached i
On 1 June 2016 at 17:31, Dietmar Eggemann wrote:
> On 30/05/16 16:52, Vincent Guittot wrote:
>> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
>> that the 1st sched_entity that will be attached, will keep its
>
> attached in .task_move_group ?
>
> I'm not sure if we can h
On 30/05/16 16:52, Vincent Guittot wrote:
> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
> that the 1st sched_entity that will be attached, will keep its
attached in .task_move_group ?
I'm not sure if we can have a .switched_to() directly followed by a
.enqueue_task()
On Tue, May 31, 2016 at 09:28:30AM +0200, Vincent Guittot wrote:
> Hi Yuyang,
>
> On 30 May 2016 at 21:48, Yuyang Du wrote:
> > On Mon, May 30, 2016 at 05:52:20PM +0200, Vincent Guittot wrote:
> >> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
> >> that the 1st sched_en
Hi Yuyang,
On 30 May 2016 at 21:48, Yuyang Du wrote:
> On Mon, May 30, 2016 at 05:52:20PM +0200, Vincent Guittot wrote:
>> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
>> that the 1st sched_entity that will be attached, will keep its
>> last_update_time set to 0 and wi
On Mon, May 30, 2016 at 05:52:20PM +0200, Vincent Guittot wrote:
> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
> that the 1st sched_entity that will be attached, will keep its
> last_update_time set to 0 and will attached once again during the
> enqueue.
> Initialize cf
The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
that the 1st sched_entity that will be attached, will keep its
last_update_time set to 0 and will attached once again during the
enqueue.
Initialize cfs_rq->avg.last_update_time to 1 instead.
Signed-off-by: Vincent Guittot
-
12 matches
Mail list logo
