On 21 March 2017 at 18:00, Vincent Guittot <vincent.guit...@linaro.org> wrote: > On 21 March 2017 at 15:58, Peter Zijlstra <pet...@infradead.org> wrote: >> >> On Tue, Mar 21, 2017 at 03:16:19PM +0100, Vincent Guittot wrote: >> > On 21 March 2017 at 15:03, Peter Zijlstra <pet...@infradead.org> wrote: >> > >> > > On Tue, Mar 21, 2017 at 02:37:08PM +0100, Vincent Guittot wrote: >> > > > On 21 March 2017 at 14:22, Peter Zijlstra <pet...@infradead.org> wrote: >> > > >> > > > For the not overloaded case, it makes sense to immediately update to >> > > > OPP to be aligned with the new utilization of the CPU even if it was >> > > > not idle in the past couple of ticks >> > > >> > > Yeah, but we cannot know. Also, who cares? >> > > >> > >> > embedded system that doesn't want to stay at higest OPP if significant part >> > of the utilzation has moved away as an example >> > AFAICT, schedutil tries to select the best OPP according to the current >> > utilization of the CPU so if the utilization decreases, the OPP should also >> > decrease >> >> Sure I get that; but given the lack of crystal ball instructions we >> cannot know if this is the case or not. > > cfs_rq->avg.load_avg account the waiting time of CPU (in addition to
sorry i wanted to say the waiting time of tasks on the CPU > the weight of task) so i was wondering if we can't use it to detect if > we are in the overloaded case or not even if utilization is not mac > capacity because we have just migrated a task (and its utilization) > out > > > >> >> And if we really dropped below 100% utilization, we should hit idle >> fairly soon.
