High cpu usage

[deanlee]

ai.comma.plus.offroad: High CPU usage around 5~10% all the time.

[geohot]

Yea it would be lovely to fix this @andyh2

offroad is the biggest CPU consumer in idle mode. When it's invisible, I don't understand why it's using any CPU at all.

[jyoung8607]

I looked at this briefly and I'm not sure this is an APK bug, or not much of one. Of the couple dozen threads running under ai.comma.plus.offroad, observing with strace -Tttyy -p [thread], only three or four are carrying out meaningful activity.

• It's trading IPC / Binder traffic with surfaceflinger for what appears to be ~60hz rendering. This is by far the most "busy" activity.
• Every five seconds it reads the params it's interested in from /data/params. I don't think this is a major contributor.

I didn't exhaustively monitor every single thread, only the ones with nonzero CPU time, but I saw no sign of SIGUSR2 (indicative of msgq activity) or other meaningful I/O. Also, the CPU burn keeps going even if boardd, thermald, ui, and athenad are killed.

offroad is the biggest CPU consumer in idle mode. When it's invisible, I don't understand why it's using any CPU at all.

I don't think it's invisible. It's invisible to humans because the display is blank, but it's blank only because openpilot's ui goes around the Android framework and turns the framebuffer display power on and off directly, without knowledge of the upper layers. The Android screen timeout on NEOS is effectively disabled. So I think it sits there rendering as if it were active in the foreground, because it is.

You can see much of this verified in certain dumpsys views. For another effective demo, try holding down the power button for a second with the screen powered off, see nothing at all happen, then touch a corner of screen to make ui.c wake it up, and you'll see the reboot/shutdown dialog, still sitting there from when it was opened with the display power off.

Options:

1. Find a way to be a better Android citizen when turning the display on and off. This might also entail holding an indefinite wakelock or other smarts to get CPU-always-on (no suspend) behavior back, since right now you're getting a free indefinite wakelock from Display-On.

2. Find a way to get offroad to get off the display foreground when the display power is off. That would make it so offroad doesn't burn CPU; I'm unsure if SurfaceFlinger can be made to calm down entirely.

[jyoung8607]

As an experiment, manually invoking Android sleep and wakeup keyevents seems to be totally effective in making surfaceflinger and offroad chill out and go to sleep, and return from sleep refreshed and ready to work again.

This alone shouldn't be merged, because the NEOS 14 kernel and OP ui are still controlling framebuffer power so things can get out of sync, but hopefully we can find a path for Android and OP to cooperate in more traditional ways, while still preserving touch wakeup.

NEOS Android doesn't seem to sleep/wakeup on the physical power button (not sure where/when that got disabled) so the usual power button key event doesn't work. Also, there are two versions of libjpeg installed on the system (Android vs termux) and the termux version doesn't have something Android is looking for, so right now you need to launch input with some manual trickery.

Command for KEYCODE_SLEEP:

LD_LIBRARY_PATH=/system/lib64:$LD_LIBRARY_PATH input keyevent 223

Command for KEYCODE_WAKEUP:

LD_LIBRARY_PATH=/system/lib64:$LD_LIBRARY_PATH input keyevent 224