A proposal for a new API for revocable kernel memory
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
- Started by
- Completed by
Whiteboard
Android offers a similar functionality which is entangled with Android's shared memory approach ashmem (see http://
There was some work going on upstream for something like this, see https:/
== 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:
There was some work going on upstream for something like this, see https:/
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