Mastodawn

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 thread

elly 2d 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 thread

Val 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 thread

robryk 2d ago

@whitequark @valpackett @elly Why including TLS? I thought TLS doesn't require inband acks, so after TCP-acking one can insert an arbitrary delay before the TLS layer sees the data, no?

Show thread

✧✦Catherine✦✧2d ago

@robryk @elly @valpackett i'm not a TLS expert so i won't comment on that part; the reason i think practically speaking you'd end up wanting to terminate TLS on the modem is because to minimize the time the SoC spends out of sleep you'd want the messages passed onto the SoC to be complete (no half-read ones where you need to wait for the rest) and useful (no passing along exchanges like "got data? no data!"). and i don't believe you can ensure that something you receive in a TLS envelope is complete because reading from a TLS stream may involve writing to the socket (i think for reasons like rekeying?)

maybe there's a way to half-ass it where it mostly works most of the time, but i've a distaste for halfassing greenfield systems

Show thread

Val Packett 🧉

@whitequark @robryk @elly IMO, batching and minimizing the time spent processing and all that is pennies. If you get the SoC to sleep for hours on end while 30-40 feral sockets are open and quietly waiting for something to happen, that's like the vast majority of the possible savings. Upon wakeup it can spend an entire minute turned on and it'll be fine. Recent SoCs just don't draw that much power when idle, this phone (SM7325/Yupik) measures 0.2W at the battery while responding to SSH commands over WiFi. That for a minute on every push, but CX rail collapsed while sleeping otherwise, would be super good. (Currently it doesn't even do CXSD yet, so suspend is not that much better than just being idle xD Still lasts an entire day without heavy screen-on use.)