A proposal for a new API for revocable kernel memory

Registered by Steve Langasek

In low-memory environments like phones, it's necessary to manage memory usage carefully between apps. But sometimes we want something a little less severe than killing and restarting backgrounded apps. One possible solution to this is to have memory that the app can denote as "revocable", that the kernel can reclaim as part of its OOM handling instead of killing the app outright. We propose a kernel API for this and discuss the necessary related userspace APIs.

Blueprint information

Status:
Not started
Approver:
Steve Langasek
Priority:
Undefined
Drafter:
Thomas Voß
Direction:
Needs approval
Assignee:
Thomas Voß
Definition:
Discussion
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Android offers a similar functionality which is entangled with Android's shared memory approach ashmem (see http://elinux.org/Android_Kernel_Features#ashmem). Ashmem allows for interprocess shared memory by means of fd-sharing and mmap'ing said fds, with the kernel parts maintaining a reference count on the shared memory region.

There was some work going on upstream for something like this, see https://lwn.net/Articles/522135/.

== Etherpad dump ==
In low-memory environments like phones, it's necessary to manage memory usage carefully between apps. But sometimes we want something a little less severe than killing and restarting backgrounded apps. One possible solution to this is to have memory that the app can denote as "revocable", that the kernel can reclaim as part of its OOM handling instead of killing the app outright. We propose a kernel API for this and discuss the necessary related userspace APIs.

Android offers a similar functionality which is entangled with Android's shared memory approach ashmem (seehttp://elinux.org/Android_Kernel_Features#ashmem). Ashmem allows for interprocess shared memory by means of fd-sharing and mmap'ing said fds, with the kernel parts maintaining a reference count on the shared memory region.
There was some work going on upstream for something like this, see https://lwn.net/Articles/522135/.

It's interesting to have:
* annonymous shared memory, that can be pinned & unpinned by external forces
* inside the app, itself pinning/unpinning what it wants to be volatile.

apw looked at a few implementations proposals (not yet in upstream Linus tree).

* Use braces instead of SIGBUS notification.

* pool allocator that could use ashmem *or* the new stuff (vrange)
* We need to iterate and gain experience with this new way of accessing memory

* workitems:
[apw] Check with upstream on status and if we can come up with a kernel that has got the revocable memory feature
[tvoss] Come up with an iteration 0 of a memory-pool API that provides access to revocable memory regionss
[apw] Come up with an iteration 0 of a memory-pool API that provides access to revocable memory regions
[slangasek] Come up with an iteration 0 of a memory-pool API that provides access to revocable memory regions
[tvoss] Note down use-cases in the blueprint, both standalone for apps and use-cases with lifecycle mgmt involved

(?)

Work Items

Work items:
[apw] Check with upstream on status and if we can come up with a kernel that has got the revocable memory feature: TODO
[thomas-voss] Come up with an iteration 0 of a memory-pool API that provides access to revocable memory regions: TODO
[thomas-voss] Note down use-cases in the blueprint, both standalone for apps and use-cases with lifecycle mgmt involved: TODO