Re: [RFC PATCH v2 0/1] cpuidle: teo: Introduce optional util-awareness

[Rafael J. Wysocki]

Hi,

On Thu, Oct 27, 2022 at 10:04 PM Lukasz Luba <lukasz.luba@xxxxxxx> wrote:
>
> Hi Rafael,
>
> On 10/13/22 12:12, Kajetan Puchalski wrote:
> > On Wed, Oct 12, 2022 at 08:50:39PM +0200, Rafael J. Wysocki wrote:
> >> On Mon, Oct 3, 2022 at 4:50 PM Kajetan Puchalski
> >> <kajetan.puchalski@xxxxxxx> wrote:
> >>>
> >>> Hi,
> >>>
> >>> At the moment, all the available idle governors operate mainly based on their own past performance
> >>
> >> Not true, at least for the menu and teo governors that use the
> >> information on the distribution of CPU wakeups that is available to
> >> them and try to predict the next idle duration with the help of it.
> >> This has a little to do with their performance.
> >
> > You're right of course, I should have written "their own past
> > correctness" as that's what I was referring to. I just meant that for
> > instance with TEO the initial timer-based choice is only adjusted using
> > the governor's own metrics and not any information from anywhere else in
> > the system.
> >
>
> [snip]
>
> Would it be possible to consider a new small and simple idle governor
> which is better suited for those other workloads and platforms?
> Kajetan has such one and can send to the LKML, so you could have a look.
>
> I have sent some detailed explanation about this to Doug in this
> thread (don't want to duplicate it).
>
> It looks like it would be hard to meet both worlds' requirements.

It may or may not be the case.  Let's first explore the original idea
of improving "teo" a bit more.

As I said in another message in this thread, there are clear cases in
which the new governor is likely to underperform, because it only
takes 2 sources of information into account (the next timer event and
CPU utilization).  If some more information is to be taken into
account without adding too much overhead, "teo" is the simplest thing
that I could imagine (but perhaps my imagination is limited).