Hi,

* Merlijn Wajer <merlijn@???> [211210 00:34]:
> Hi,
>
> I've spent the day bisecting what exact commit prevented the Nokia N900
> from entering the OFF sleep state (between v5.8 and v5.9), and it this
> commit:
>
> > # first bad commit: [facdaa917c4d5a376d09d25865f5a863f906234a] mm: proactive compaction
>
> The git tree prior to that commit can idle at about ~27mW in OFF mode,
> and it will often remain in that mode for prolonged amounts of time
> (easily 30 seconds, depending on running userspace). Which the above
> commit applied, the Nokia N900 almost never hits OFF mode any more. This
> would suggest at least to disable CONFIG_COMPACTION, perhaps in
> omap2plus_defconfig? I suspect this might cause idle problems beyond the
> Nokia N900, too.

Nice find, adding Nitin to Cc as well. Nitin, can we somehow avoid the
timers for CONFIG_COMPACTION on an idle system to prevent waking up the
system unnecessarily?

Not sure if sysctl -w vm.compaction_proactiveness=0 is enough to disable
compaction for idle, maybe also the HPAGE_FRAG_CHECK_INTERVAL_MSEC = 500
at ms also causes extra wake-ups?

Regards,

Tony

> Maybe nothing needs to be done here other than disable the config option
> -- but I wanted to share this in case others are trying to figure out
> what happened to their battery life. :-)
>
> There seem be more power regressions since then (at least on 5.15 there
> is more blocking proper idle), so I'll try to find those as well, but if
> this commit is reverted (or CONFIG_COMPACTION=n is in .config - probably
> easier) on top of v5.9 the system seems to idle fine.
>
> > # grep ^core_pwrdm /sys/kernel/debug/pm_debug/count | cut -d',' -f2,
> > OFF:16,RET:2
>
> Hope this helps someone...
>
> Regards,
> Merlijn
>
> PS: v5.10 seems to use another 19mW if panel_sony_acx565akm is loaded
> even when display is not active (maybe it doesn't suspend or something?
> - could be fixed later, just noticed it for v5.10). I load it initially
> to idle the display, but until I rmmod the modules, the module uses
> quite a bit more power. This problem is not present in v5.9, so that is
> another thing to chase down I guess... And then v5.15 uses another 12mW
> more, for not yet uncovered reasons)