Re: TEO as default governor ?

[Christian Loehle <christian.loehle@arm.com>]

On 3/11/25 18:00, Daniel Lezcano wrote:
> On 11/03/2025 18:34, Rafael J. Wysocki wrote:
>> On Tue, Mar 11, 2025 at 5:47 PM Christian Loehle
>> <christian.loehle@arm.com> wrote:
>>>
>>> On 3/11/25 16:31, Daniel Lezcano wrote:
>>>>
>>>> Hi,
>>>>
>>>> I think we can agree the teo governor is better then the menu governor.
>>>>
>>>> Would it make sense to make the teo governor the default governor ?
>>>>
>>>>
>>>
>>> Rafael's position seems to be quite conservative here.
>>> Fact is menu is still the default on many systems.
>>> Even worse, the really bad performance disadvantage when
>>> using menu in an intercept-heavy workload has been fixed by Rafael :)
>>> https://lore.kernel.org/lkml/bc7f915b-8d9f-4e05-9939-8b7ecc078f85@arm.com/
>>>
>>> FWIW I proposed this a while ago:
>>> https://lore.kernel.org/lkml/20240905092645.2885200-3-christian.loehle@arm.com/
>>
>> It will help if one can make a really convincing case for this change
>> (that is, show that menu with the most recent fixes included is really
>> significantly worse on their platform).
> 
> For all the platforms I've been testing, the teo governor is always the best one.
> 
> Using the menu governor has also an impact on the user experience as it lags on mobile.
> 
> After studying the history of the menu governor few years ago, it appeared the menu governor was introduced before the SMP was widely used. The strength of the menu governor was the ability to find repeating intervals but with he multiplication of the cores, the IPIs were introduced which increased the entropy of the busy-idle cycles duration, thus making the duration much more random and altering the menu governor prediction accuracy.

Cross-posting Doug's reply here and +CC
https://lore.kernel.org/lkml/005801db9397$266ddac0$73499040$@telus.net/

Daniel if you're testing both and struggle to find a strong advantage
for teo:
teo currently has the intercept-mechanism, trying to find a shallower state
until we are at < 1/2 intercepts as wakeups.
Rafael's idea was to make this configurable, e.g. allowing only 20%
intercepts (more aggressive in selecting shallow states) or 80% (less
aggressive in selecting shallow states).
This would be a minimal change in code and the rest of teo is unaffected,
but gives users a choice, something menu won't offer.