[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0iese2fs30vrz2_NiR5rMgct21L3ddy5MDapqcSPY2DKg@mail.gmail.com>
Date: Fri, 28 Oct 2022 15:25:22 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Daniel Lezcano <daniel.lezcano@...aro.org>
Cc: Kajetan Puchalski <kajetan.puchalski@....com>,
"Rafael J. Wysocki" <rafael@...nel.org>, lukasz.luba@....com,
Dietmar.Eggemann@....com, dsmythies@...us.net,
yu.chen.surf@...il.com, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 0/1] cpuidle: teo: Introduce optional util-awareness
On Thu, Oct 20, 2022 at 9:52 PM Daniel Lezcano
<daniel.lezcano@...aro.org> wrote:
>
>
> Hi Kajetan,
>
> On 20/10/2022 18:20, Kajetan Puchalski wrote:
> > Hi Rafael,
> >
> >> The avg_util value tells us nothing about how much the CPU is going to
> >> be idle this time and it also tells us nothing about the
> >> latency-sensitivity of the workload.
> >>
> >> Yes, it tells us how much idle time there was on the given CPU in the
> >> past, on the average, but there is zero information about the
> >> distribution of that idle time in it.
> >>
> >> So in the first place please tell me why it fundamentally makes sense
> >> to use avg_util in CPU idle time management at all.
> >
> > I have an alternative suggestion that could be a reasonable way forward
> > here. Instead of applying util-awareness on top of TEO where it would
> > have to be reconciled with how TEO is currently expected to work, I just
> > wrote a simple completely new governor which operates only on timer
> > events alongside util values.
>
> I second the idea. I took a long time to investigate how to improve the
> governor and reached the conclusion having a dedicated governor for
> mobile platform makes sense.
Please define "mobile".
> Also the behavior is very platform dependent.
I'm not sure what you mean.
Powered by blists - more mailing lists