Val Packett 🧉2d ago

In preparation for daily driving #MobileLinux I've been thinking a lot about what must be done for reliable and power-efficient push notifications.

Spoiler alert: while UnifiedPush may be a relevant service for some apps, it's not where platform dev focus should be. We want a future full of p2p apps that reject permanently-addressable "servers" entirely, after all! And centralization is not where the bulk of the power-saving magic is anyway. The "magic" is in the fact that the SoC can be in deep sleep and the modem will still wake it up with an interrupt when data arrives on an open connection. It should be fine to have apps' own service processes listen for notifications!

My rough sketch of a to-do list would be:

  • making sure wakeups don't turn the display on xD
  • research into what's needed to set up filtering on the modem for which sockets can wake the SoC up (but initially, fine to just rely on "nothing else has open sockets anyway, only the background services waiting for pushes" maybe?)
  • easy API for establishing the push connection specifically over mobile data if available (since only modem supports wakeup well rn)
  • support for robust background services: unlike what the Background portal offers now, let #Flatpak apps install systemd-user services, which would have metadata connecting them to the .desktop entry, making them introspectable and accountable via settings GUIs (not via control center popups! they shouldn't show up as "annoying left-over in-process thing possibly eating battery"! they're a different thing, expected to run permanently!)
  • actually getting apps to separate push notification listeners into background services

#postmarketOS #linuxmobile #freedesktop

Show threadelly2d ago
@valpackett I had similar thoughts, together with "wake up only bare minimum" (single CPU core, modem and ADSP, leave DSI, CSI, I2C/SPI/UART blocks in suspend (if possible, not sure if this can be done... I guess you can tell pinctrl to leave pins in pull-down mode?)

We don't need to wake up the entire SoC for this, which would drastically reduce the power draw (and therefore the battery life)
Show threadVal Packett 🧉2d ago

@elly just not turning on the display would leave DSI off, and if touchscreen is a panel-follower also that with the SPI/I2C used for it. that's all already managed by runtime pm!

USB of all things just is not there yet, it does pm_runtime_forbid() still (you can override that by echoing auto into power/control for all usb, xhci-hcd and related phy nodes and pray xD)

not enabling more than one CPU core until there's actual activity is very interesting yeah. somewhat related is using scx-lavd as the scheduler which does try to bunch tasks together onto one cluster to keep the others in suspend as much as possible. but hard "only 1 core online until the session is open" would be a nice big hammer :D

oh oh I also forgor for the list: bg services will need to have some way of opening the push connection specifically over the mobile data interface if available (unless specific-enough wakeup is possible with wifi after all)

Show thread✧✦Catherine✦✧2d ago

@valpackett @elly how does this solve the problem of "five applications independently maintain event sockets resulting in approximately five times the amount of wakeups"? the advantage of something like gms (no idea if unified push actually does it) is that it can batch events from unrelated sources into one wakeup

in theory, if you terminated all of the connections, including TLS, on the modem, you could achieve the same level of power savings. in practice i absolutely do not want to terminate TLS on the modem, that's horrifying

Show threadelly2d ago
@whitequark @valpackett then you will be horrified to find out that smasnug modems (Samsung phones with Exynos SoC, Google Pixel 6 and newer) have a modem where ARM SoC (Control Processor, "CP") running ShannonOS (RTOS) is connected over PCIe and it's running a full IP stack on that RTOS.

AFAIK UnifiedPush does exactly that, I've seen a presentation about it and it acts kinda like GSF do.
Show thread✧✦Catherine✦✧2d ago

@elly @valpackett I'm not surprised at all that this exists (the modem is obviously capable of it and this is obviously desirable from a vendor's point of view), but I'm very surprised that there is both the desire and the capability to use that sort of stuff in FOSS ROM components

is this mechanism at least somewhat portable? do you want to keep using it? if the answers are yes then yeah aggregation on the modem is the way to go, I'm just surprised to see FOSS-minded people be okay letting that blob handle anything important

Show thread✧✦Catherine✦✧
@elly @valpackett i found this slide deck which doesn't say anything about terminating connections on the modem, is there a different presentation? couldn't find anything in UP docs either
Mar 23 at 1:29amWeb
Show threadelly2d ago
@whitequark @valpackett Ah, that's not what I meant. Sorry, I meant two different things.

UnifiedPush works completely in userspace
Show thread✧✦Catherine✦✧2d ago
@elly @valpackett okay yeah then to clarify my earlier statement: it horrifies me because the modem is some blob we don't control that is typically tested and built much more shoddily than the AP firmware (do they normally enable NX and stack cookies on it yet?), not because there's anything wrong with the abstract concept of 'brains in the modem'
Show threadCUB3D2d ago
@whitequark On Shannon specifically: NX is enabled, it has stack cookies and they started enabling some LLVM sanitizers. No CFI/PAC/ASLR. Slightly better than other modems, but whether their custom RTOS actually implements any of it *correctly* is anyone's guess.