Hi, * Merlijn Wajer <merlijn@xxxxxxxxxx> [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)
