[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f799f67c-c9e9-c702-8457-db8da78500c9@arm.com>
Date: Thu, 27 Oct 2022 21:04:50 +0100
From: Lukasz Luba <lukasz.luba@....com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: daniel.lezcano@...aro.org, Dietmar.Eggemann@....com,
dsmythies@...us.net, yu.chen.surf@...il.com,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
Kajetan Puchalski <kajetan.puchalski@....com>
Subject: Re: [RFC PATCH v2 0/1] cpuidle: teo: Introduce optional
util-awareness
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@....com> 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.
Regards,
Lukasz
Powered by blists - more mailing lists