[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKfTPtBRjWVqbDhAVFr1DhUe-HssMu7gMGJXpCo=+TvRQeLfsA@mail.gmail.com>
Date: Thu, 16 Jun 2016 21:00:57 +0200
From: Vincent Guittot <vincent.guittot@...aro.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Yuyang Du <yuyang.du@...el.com>, Ingo Molnar <mingo@...nel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Mike Galbraith <umgwanakikbuti@...il.com>,
Benjamin Segall <bsegall@...gle.com>,
Paul Turner <pjt@...gle.com>,
Morten Rasmussen <morten.rasmussen@....com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Matt Fleming <matt@...eblueprint.co.uk>
Subject: Re: [PATCH v6 1/4] sched/fair: Fix attaching task sched avgs twice
when switching to fair or changing task group
On 16 June 2016 at 20:51, Peter Zijlstra <peterz@...radead.org> wrote:
> On Thu, Jun 16, 2016 at 06:30:13PM +0200, Vincent Guittot wrote:
>> With patch [1] for the init of cfs_rq side, all use cases will be
>> covered regarding the issue linked to a last_update_time set to 0 at
>> init
>> [1] https://lkml.org/lkml/2016/5/30/508
>
> Aah, wait, now I get it :-)
>
> Still, we should put cfs_rq_clock_task(cfs_rq) in it, not 1. And since
> we now acquire rq->lock on init this should well be possible. Lemme sort
> that.
yes with the rq->lock we can use cfs_rq_clock_task which is make more
sense than 1.
But the delta can be still significant between the creation of the
task group and the 1st task that will be attach to the cfs_rq
Powered by blists - more mailing lists