On 10/18/19 8:59 AM, Peter Zijlstra wrote:
> On Fri, Oct 18, 2019 at 09:44:44AM +0200, Dietmar Eggemann wrote:
>> On 17/10/2019 16:11, Peter Zijlstra wrote:
>>> On Thu, Oct 17, 2019 at 12:11:16PM +0100, Quentin Perret wrote:
>>
>> [...]
>>
>>> It only boosts when 'rq->cfs.avg.util' increases
On 10/18/19 4:15 PM, Vincent Guittot wrote:
> On Fri, 18 Oct 2019 at 16:44, Douglas Raillard
> wrote:
>>
>>
>>
>> On 10/18/19 1:07 PM, Peter Zijlstra wrote:
>>> On Fri, Oct 18, 2019 at 12:46:25PM +0100, Douglas Raillard wrote:
>>>
> What I don't see is how that that difference makes sense
On Fri, 18 Oct 2019 at 16:44, Douglas Raillard wrote:
>
>
>
> On 10/18/19 1:07 PM, Peter Zijlstra wrote:
> > On Fri, Oct 18, 2019 at 12:46:25PM +0100, Douglas Raillard wrote:
> >
> >>> What I don't see is how that that difference makes sense as input to:
> >>>
> >>> cost(x) : (1 + x) * cost_j
On Fri, 18 Oct 2019 at 16:44, Douglas Raillard wrote:
>
>
>
> On 10/18/19 1:07 PM, Peter Zijlstra wrote:
> > On Fri, Oct 18, 2019 at 12:46:25PM +0100, Douglas Raillard wrote:
> >
> >>> What I don't see is how that that difference makes sense as input to:
> >>>
> >>> cost(x) : (1 + x) * cost_j
On 10/18/19 1:07 PM, Peter Zijlstra wrote:
On Fri, Oct 18, 2019 at 12:46:25PM +0100, Douglas Raillard wrote:
What I don't see is how that that difference makes sense as input to:
cost(x) : (1 + x) * cost_j
The actual input is:
x = (EM_COST_MARGIN_SCALE/SCHED_CAPACITY_SCALE) * (util -
On Fri, Oct 18, 2019 at 12:46:25PM +0100, Douglas Raillard wrote:
> > What I don't see is how that that difference makes sense as input to:
> >
> >cost(x) : (1 + x) * cost_j
>
> The actual input is:
> x = (EM_COST_MARGIN_SCALE/SCHED_CAPACITY_SCALE) * (util - util_est)
>
> Since
On 10/17/19 8:07 PM, Peter Zijlstra wrote:
On Thu, Oct 17, 2019 at 03:23:04PM +0100, Douglas Raillard wrote:
On 10/17/19 10:50 AM, Peter Zijlstra wrote:
I'm still thinking about the exact means you're using to raise C; that
is, the 'util - util_est' as cost_margin. It hurts my brain
On Fri, Oct 18, 2019 at 09:44:44AM +0200, Dietmar Eggemann wrote:
> On 17/10/2019 16:11, Peter Zijlstra wrote:
> > On Thu, Oct 17, 2019 at 12:11:16PM +0100, Quentin Perret wrote:
>
> [...]
>
> > It only boosts when 'rq->cfs.avg.util' increases while
> > 'rq->cfs.avg.util_est.enqueued' remains
On Fri, Oct 18, 2019 at 09:44:44AM +0200, Dietmar Eggemann wrote:
> On 17/10/2019 16:11, Peter Zijlstra wrote:
> > On Thu, Oct 17, 2019 at 12:11:16PM +0100, Quentin Perret wrote:
>
> [...]
>
> > It only boosts when 'rq->cfs.avg.util' increases while
> > 'rq->cfs.avg.util_est.enqueued' remains
On 17/10/2019 16:11, Peter Zijlstra wrote:
> On Thu, Oct 17, 2019 at 12:11:16PM +0100, Quentin Perret wrote:
[...]
> It only boosts when 'rq->cfs.avg.util' increases while
> 'rq->cfs.avg.util_est.enqueued' remains unchanged (and util > util_est
> obv).
>
> This condition can be true for
On Thu, Oct 17, 2019 at 03:23:04PM +0100, Douglas Raillard wrote:
> On 10/17/19 10:50 AM, Peter Zijlstra wrote:
> > I'm still thinking about the exact means you're using to raise C; that
> > is, the 'util - util_est' as cost_margin. It hurts my brain still.
>
> util_est is currently the best
On Thu, Oct 17, 2019 at 03:23:04PM +0100, Douglas Raillard wrote:
> On 10/17/19 10:50 AM, Peter Zijlstra wrote:
> > Now, the thing is, we use map_util_freq() in more places, and should we
> > not reflect this increase in C for all of them? That is, why is this
> > patch changing get_next_freq()
Hi Peter,
On 10/17/19 10:50 AM, Peter Zijlstra wrote:
On Mon, Oct 14, 2019 at 04:50:24PM +0100, Douglas Raillard wrote:
I posted some numbers based on a similar experiment on the v2 of that series
that
are still applicable:
TL;DR the rt-app negative slack is divided by 1.75 by this series,
On Thu, Oct 17, 2019 at 12:11:16PM +0100, Quentin Perret wrote:
> On Thursday 17 Oct 2019 at 11:50:15 (+0200), Peter Zijlstra wrote:
> > Now, the thing is, we use map_util_freq() in more places, and should we
> > not reflect this increase in C for all of them? That is, why is this
> > patch
On Thursday 17 Oct 2019 at 11:50:15 (+0200), Peter Zijlstra wrote:
> Now, the thing is, we use map_util_freq() in more places, and should we
> not reflect this increase in C for all of them? That is, why is this
> patch changing get_next_freq() and not map_util_freq().
>
> I don't think that
On Mon, Oct 14, 2019 at 04:50:24PM +0100, Douglas Raillard wrote:
> I posted some numbers based on a similar experiment on the v2 of that series
> that
> are still applicable:
>
> TL;DR the rt-app negative slack is divided by 1.75 by this series, with an
> increase of 3% in total energy
Hi Peter,
On 10/14/19 3:53 PM, Peter Zijlstra wrote:
On Fri, Oct 11, 2019 at 02:44:54PM +0100, Douglas RAILLARD wrote:
This has been ligthly tested with a rtapp task ramping from 10% to 75%
utilisation on a big core. Results are improved by fast ramp-up
EWMA [1], since it greatly reduces the
On Fri, Oct 11, 2019 at 02:44:54PM +0100, Douglas RAILLARD wrote:
> This has been ligthly tested with a rtapp task ramping from 10% to 75%
> utilisation on a big core. Results are improved by fast ramp-up
> EWMA [1], since it greatly reduces the oscillation in frequency at first
> idle when
Make schedutil cpufreq governor energy-aware.
- patch 1 introduces a function to retrieve a frequency given a base
frequency and an energy cost margin.
- patch 2 links Energy Model perf_domain to sugov_policy.
- patch 3 updates get_next_freq() to make use of the Energy Model.
- patch 4 adds
19 matches
Mail list logo
