On 10/25/18 12:43 PM, Vincent Guittot wrote:
On Thu, 25 Oct 2018 at 12:36, Dietmar Eggemann wrote:
[...]
I have a couple of questions related to the tests you ran.
On a hikey (octo ARM platform).
Performance cpufreq governor and only shallowest c-state to remove variance
generated by
On 10/25/18 12:43 PM, Vincent Guittot wrote:
On Thu, 25 Oct 2018 at 12:36, Dietmar Eggemann wrote:
[...]
I have a couple of questions related to the tests you ran.
On a hikey (octo ARM platform).
Performance cpufreq governor and only shallowest c-state to remove variance
generated by
On Thu, 25 Oct 2018 at 12:36, Dietmar Eggemann wrote:
>
> Hi Vincent,
>
> On 10/19/18 6:17 PM, Vincent Guittot wrote:
> > The current implementation of load tracking invariance scales the
> > contribution with current frequency and uarch performance (only for
> > utilization) of the CPU. One main
On Thu, 25 Oct 2018 at 12:36, Dietmar Eggemann wrote:
>
> Hi Vincent,
>
> On 10/19/18 6:17 PM, Vincent Guittot wrote:
> > The current implementation of load tracking invariance scales the
> > contribution with current frequency and uarch performance (only for
> > utilization) of the CPU. One main
Hi Vincent,
On 10/19/18 6:17 PM, Vincent Guittot wrote:
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current
Hi Vincent,
On 10/19/18 6:17 PM, Vincent Guittot wrote:
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current
Hi Pavan,
On Wed, 24 Oct 2018 at 06:53, Pavan Kondeti wrote:
>
> Hi Vincent,
>
> Thanks for the detailed explanation.
>
> On Tue, Oct 23, 2018 at 02:15:08PM +0200, Vincent Guittot wrote:
> > Hi Pavan,
> >
> > On Tue, 23 Oct 2018 at 07:59, Pavan Kondeti wrote:
> > >
> > > Hi Vincent,
> > >
> >
Hi Pavan,
On Wed, 24 Oct 2018 at 06:53, Pavan Kondeti wrote:
>
> Hi Vincent,
>
> Thanks for the detailed explanation.
>
> On Tue, Oct 23, 2018 at 02:15:08PM +0200, Vincent Guittot wrote:
> > Hi Pavan,
> >
> > On Tue, 23 Oct 2018 at 07:59, Pavan Kondeti wrote:
> > >
> > > Hi Vincent,
> > >
> >
Hi Vincent,
Thanks for the detailed explanation.
On Tue, Oct 23, 2018 at 02:15:08PM +0200, Vincent Guittot wrote:
> Hi Pavan,
>
> On Tue, 23 Oct 2018 at 07:59, Pavan Kondeti wrote:
> >
> > Hi Vincent,
> >
> > On Fri, Oct 19, 2018 at 06:17:51PM +0200, Vincent Guittot wrote:
> > >
> > > /*
> >
Hi Vincent,
Thanks for the detailed explanation.
On Tue, Oct 23, 2018 at 02:15:08PM +0200, Vincent Guittot wrote:
> Hi Pavan,
>
> On Tue, 23 Oct 2018 at 07:59, Pavan Kondeti wrote:
> >
> > Hi Vincent,
> >
> > On Fri, Oct 19, 2018 at 06:17:51PM +0200, Vincent Guittot wrote:
> > >
> > > /*
> >
Hi Pavan,
On Tue, 23 Oct 2018 at 07:59, Pavan Kondeti wrote:
>
> Hi Vincent,
>
> On Fri, Oct 19, 2018 at 06:17:51PM +0200, Vincent Guittot wrote:
> >
> > /*
> > + * The clock_pelt scales the time to reflect the effective amount of
> > + * computation done during the running delta time but then
Hi Pavan,
On Tue, 23 Oct 2018 at 07:59, Pavan Kondeti wrote:
>
> Hi Vincent,
>
> On Fri, Oct 19, 2018 at 06:17:51PM +0200, Vincent Guittot wrote:
> >
> > /*
> > + * The clock_pelt scales the time to reflect the effective amount of
> > + * computation done during the running delta time but then
On Tue, 23 Oct 2018 at 12:01, Peter Zijlstra wrote:
>
> On Fri, Oct 19, 2018 at 06:17:51PM +0200, Vincent Guittot wrote:
> > In order to achieve this time scaling, a new clock_pelt is created per rq.
>
>
> > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > index 3990818..d987f50
On Tue, 23 Oct 2018 at 12:01, Peter Zijlstra wrote:
>
> On Fri, Oct 19, 2018 at 06:17:51PM +0200, Vincent Guittot wrote:
> > In order to achieve this time scaling, a new clock_pelt is created per rq.
>
>
> > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > index 3990818..d987f50
On Fri, Oct 19, 2018 at 06:17:51PM +0200, Vincent Guittot wrote:
> In order to achieve this time scaling, a new clock_pelt is created per rq.
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 3990818..d987f50 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@
On Fri, Oct 19, 2018 at 06:17:51PM +0200, Vincent Guittot wrote:
> In order to achieve this time scaling, a new clock_pelt is created per rq.
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 3990818..d987f50 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@
Hi Vincent,
On Fri, Oct 19, 2018 at 06:17:51PM +0200, Vincent Guittot wrote:
>
> /*
> + * The clock_pelt scales the time to reflect the effective amount of
> + * computation done during the running delta time but then sync back to
> + * clock_task when rq is idle.
> + *
> + *
> + * absolute
Hi Vincent,
On Fri, Oct 19, 2018 at 06:17:51PM +0200, Vincent Guittot wrote:
>
> /*
> + * The clock_pelt scales the time to reflect the effective amount of
> + * computation done during the running delta time but then sync back to
> + * clock_task when rq is idle.
> + *
> + *
> + * absolute
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not
20 matches
Mail list logo
