Process Management

One of the goals of Mobian is to discover a balance between the needs of mobile hardware and the wealth of available software in the Debian ecosystem. With the default install of Mobian on the PinePhone apps generally run fine as long as you don't run too many of them at once or you are close to a power source. The PinePhone only comes with 2GB (or 3GB if you have the special edition) of RAM and that quickly becomes exhausted with several apps that were intended to run on a desktop lass machine with much more RAM and possibly a swap. Also, desktop apps generally don't concern themselves with power consumption. It is hoped that there will be some way to intelligently pause apps that are not in active use so that they don't consume so much power or system RAM. Note that CRUST saves power while the phone is sleeping by suspending the entire OS while process management relates to power consumption while the phone is in active use.

Two approaches are being considered so far to suspend inactive processes. There needs to be a mechanism to determine determine which processes to suspend. That is discussed later on.

In the world of docker containers there was a need to be able to suspend and resume containers to facilitate their transfer to different machines. This becomes really useful for transparent upgrades or machine replacement in data centers. This is where CRIU comes in. A number of Linux kernel changes have been made to support “checkpoint” and “restore” of groups of Linux processes so that their state is saved to a directory on disk and resumed using that information at a later time. There's even support for restoring active TCP connections. But, there is an overall problem of managing what is called “external dependencies,” which are any inter-process resources (e.g. named pipes, ghost files) that are shared with processes that live outside the collection that will be suspended. For these, there is a system of domain specific plugins that can help. At one point in the past there was a proposal for supporting Wayland's named pipes for GUI programs, but it seems not to have ever materialized.

CRIU cleanly stops groups of processes so that they no longer consume any power or RAM and dumps their state to disk making it conceptually very simple. Some initial testing proves that CRIU can work for simple command-line applications. However, Wayland applications will likely be some of the best candidates for suspension but it has been confirmed that the named pipe is not currently handled by CRIU and is crucial to the function of Wayland apps and so it is unlikely to change.

Another approach that has been discussed is to simply put chosen processes into a stopped state where the Linux scheduler gives that process no more CPU time until it is continued. This is done using Linux signals SIGSTOP to stop a process and then SIGCONT to resume it. It is a similar, but not identical approach to the way that you can background a process from a shell using Ctrl-z and fg.

$ kill -STOP 11346
# Process 11346 is now in a stopped state
$ kill -CONT 11345
# Process 11346 is now in a resumed continued state

Note that signals can also be sent to all processes in a process group. In fact, this is how the shell handles job management, but the signal is SIGTSTP instead. Unfortunately, apps launched from Phosh are not given their own process groups. Here is the source for a simple “killtree” command that will recurse a process's children processes and send each the signal.

#!/bin/bash
# killtree.sh <signal> <pid>
list_descendants ()
{
  local children=$(ps -o pid= --ppid "$1")

  for pid in $children
  do
    list_descendants "$pid"
  done

  echo "$children"
}

kill $1 $2 $(list_descendants $2)

The theory goes that since these processes will never get any CPU time while stopped there will never be any more page faults to bring virtual memory pages from swap into system RAM. Also, any active processes will generate page faults that will force the Linux VMM to start swapping the stopped processes pages to swap given enough contention in the system RAM. In testing, this does appear to be the case since active processes seem to run more quickly and it is possible to run more of them compared to leaving all processes as active.

If a process is stopped then the Linux kernel should be able to save the power since the system is less active. Resuming stopped processes appears to be relatively fast although there could be some time spent page faulting the active memory pages back into system RAM.

While this approach seems to be viable for the most part right now there are some concerns. First, using actual swap partition or swap file on a flash device such as eMMC or SD Card could cause excessive wear on the device leading to premature failure. It is believed that this problem might be partially mitigated by Linux's batching of writes to the swap, but this hasn't been effectively verified. Although, it is possible that ZRAM would avoid this problem entirely.

When shutting down or rebooting Linux when there are stopped processes the shutdown process appears to hang. There will need to be some way to continue any stopped processes automatically when a shutdown or reboot occurs to prevent any hanging.

A possibly related idea is this Linux “game mode” project that aims to give the active game processes better priority over system resources. https://github.com/FeralInteractive/gamemode

The above two approaches will only work if there is a way to identify processes that are good candidates for suspension. A very simplistic approach could be to suspend every tree of processes associated with a window that is not the current active window. When a different window is activated then some event could trigger the suspension of all other windows and resume the current one.

However, this approach is not without its technical difficulties. It is not yet clear how to get these kinds of global window events via Phosh, Wayland or some other means like D-Bus. It does seem probably that a solution might be found.

Once you have the event mechanism worked out and the process ID found for the top-level process how can one be sure that the process tree encompasses all active processes serving this window? Web browsers, such as Firefox and Epiphany, can have multiple windows but a set of shared processes to perform the work. It is unclear at the moment whether these might be the few exceptions cases among the apps that people will run on the mobile devices and could somehow be exempted.

Also, what about media players where users might expect them to continue playing the audio in the background while the user temporarily uses some other app? Again, perhaps these can be declared as exceptions to the normal policy?

Other apps might occasionally need some every few minutes to resume their activities because they might generate notifications for the user. Maybe this is another class of applications that need some special exceptions? Maybe there is a better way for Linux apps to separate this background notification into a service used by the app itself that also generates notifications.

While front end applications might be good targets for suspension one might also need to consider various back-end services that can under certain kinds of load occupy system RAM and consume power. The gnome software agent comes to mind as it periodically uses fairly substantial RAM and CPU.

Finally, how would all of this interact with CRUST so that the highest priority processes get resumed very quickly on wakeup, such as phone calls or SMS? Alternatively, when CRUST wakes up the OS periodically, how to get the right processes activated quickly enough to generate notifications before being suspended again?

As a reference SailfishOS uses this to help identify candidates for suspension: https://git.sailfishos.org/mer-core/nemo-keepalive