On 30-Jun 10:43, Vincent Guittot wrote: > On Fri, 28 Jun 2019 at 16:10, Patrick Bellasi <patrick.bell...@arm.com> wrote: > > On 28-Jun 15:51, Vincent Guittot wrote: > > > On Fri, 28 Jun 2019 at 14:38, Peter Zijlstra <pet...@infradead.org> wrote: > > > > On Fri, Jun 28, 2019 at 11:08:14AM +0100, Patrick Bellasi wrote: > > > > > On 26-Jun 13:40, Vincent Guittot wrote:
Hi Vincent, [...] > > > AFAICT, it's not related to the time-scaling > > > > > > In fact the big 1st activation happens because task runs at low OPP > > > and hasn't enough time to finish its running phase before the time to > > > begin the next one happens. This means that the task will run several > > > computations phase in one go which is no more a 75% task. > > > > But in that case, running multiple activations back to back, should we > > not expect the util_avg to exceed the 75% mark? > > But task starts with a very low value and Pelt needs time to ramp up. Of course... [...] > > > Once cpu reaches a high enough OPP that enable to have sleep phase > > > between each running phases, the task load tracking comes back to the > > > normal slope increase (the one that would have happen if task would > > > have jump from 5% to 75% but already running at max OPP) > > > > > > Indeed, I can see from the plots a change in slope. But there is also > > that big drop after the first big activation: 375 units in 1.1ms. > > > > Is that expected? I guess yes, since we fix the clock_pelt with the > > lost_idle_time. ... but, I guess Peter was mainly asking about the point above: is that "big" drop after the first activation related to time-scaling or not? Cheers, Patrick -- #include <best/regards.h> Patrick Bellasi
