On 22/02/2021 17:23, Quentin Perret wrote:
> On Monday 22 Feb 2021 at 15:58:56 (+), Quentin Perret wrote:
>> But in any case, if we're going to address this, I'm still not sure this
>> patch will be what we want. As per my first comment we need to keep the
>> frequency estimation right.
>
>
On 22/02/2021 10:54, vincent.donnef...@arm.com wrote:
> From: Vincent Donnefort
[...]
> Also, replace sub_positive with lsub_positive which saves one explicit
> load-store.
IMHO, in case you're going to fix this now in compute_energy(), this
optimization could still be done. Maybe in an extra
On Monday 22 Feb 2021 at 16:39:47 (+), Vincent Donnefort wrote:
> On Mon, Feb 22, 2021 at 04:23:42PM +, Quentin Perret wrote:
> > On Monday 22 Feb 2021 at 15:58:56 (+), Quentin Perret wrote:
> > > But in any case, if we're going to address this, I'm still not sure this
> > > patch will
On Mon, Feb 22, 2021 at 04:23:42PM +, Quentin Perret wrote:
> On Monday 22 Feb 2021 at 15:58:56 (+), Quentin Perret wrote:
> > But in any case, if we're going to address this, I'm still not sure this
> > patch will be what we want. As per my first comment we need to keep the
> > frequency
On Monday 22 Feb 2021 at 16:31:08 (+), Vincent Donnefort wrote:
> I suppose, a way of fixing this, is to keep cpu_util_next() the way it is to
> get the appropriate frequency at which the CPU would run once the task has
> been
> enqueued, for the 'max_util', and have 'sum_util' being the sum
On Mon, Feb 22, 2021 at 03:58:56PM +, Quentin Perret wrote:
> On Monday 22 Feb 2021 at 15:01:51 (+), Vincent Donnefort wrote:
> > You mean that it could lead to a wrong frequency estimation when doing
> > freq = map_util_freq() in em_cpu_energy()?
>
> I'm not too worried about the
On Monday 22 Feb 2021 at 15:58:56 (+), Quentin Perret wrote:
> But in any case, if we're going to address this, I'm still not sure this
> patch will be what we want. As per my first comment we need to keep the
> frequency estimation right.
Totally untested, but I think in principle you would
On Monday 22 Feb 2021 at 15:01:51 (+), Vincent Donnefort wrote:
> You mean that it could lead to a wrong frequency estimation when doing
> freq = map_util_freq() in em_cpu_energy()?
I'm not too worried about the map_util_freq() part, I'm worried about
the schedutil aggregation. Specifically,
On Mon, Feb 22, 2021 at 12:23:04PM +, Quentin Perret wrote:
> On Monday 22 Feb 2021 at 11:36:03 (+), Vincent Donnefort wrote:
> > Here's with real life numbers.
> >
> > The task: util_avg=3 (1) util_est=11 (2)
> >
> > pd0 (CPU-0, CPU-1, CPU-2)
> >
> > cpu_util_next(CPU-0, NULL): 7
> >
On Monday 22 Feb 2021 at 11:36:03 (+), Vincent Donnefort wrote:
> Here's with real life numbers.
>
> The task: util_avg=3 (1) util_est=11 (2)
>
> pd0 (CPU-0, CPU-1, CPU-2)
>
> cpu_util_next(CPU-0, NULL): 7
> cpu_util_next(CPU-1, NULL): 3
> cpu_util_next(CPU-2, NULL): 0 <- Most capacity,
Hi Quentin,
On Mon, Feb 22, 2021 at 10:11:03AM +, Quentin Perret wrote:
> Hey Vincent,
>
> On Monday 22 Feb 2021 at 09:54:01 (+), vincent.donnef...@arm.com wrote:
> > From: Vincent Donnefort
> >
> > Currently, cpu_util_next() estimates the CPU utilization as follows:
> >
> >
Hey Vincent,
On Monday 22 Feb 2021 at 09:54:01 (+), vincent.donnef...@arm.com wrote:
> From: Vincent Donnefort
>
> Currently, cpu_util_next() estimates the CPU utilization as follows:
>
> max(cpu_util + task_util,
> cpu_util_est + task_util_est)
s/task_util_est/_task_util_est
From: Vincent Donnefort
Currently, cpu_util_next() estimates the CPU utilization as follows:
max(cpu_util + task_util,
cpu_util_est + task_util_est)
This is an issue when making a comparison between CPUs, as the task
contribution can be either:
(1) task_util_est, on a mostly idle
13 matches
Mail list logo
