Edited by Jesse Barker. Send review comments to email@example.com.
The intent of this document is to outline the use cases and requirements that have motivated the implementation of not one, but several general memory provider mechanisms on ARM-based embedded platforms. Each endeavor seems to have started with both an API and a default implementation that addressed a particular set of problems at hand. Overall, this creates a large maintenance burden both on the vendors of those solutions as well as on the other software layers that consume these services. As the input to this document is an unconnected set of e-mail threads, the goal here is to try to improve the collective understanding of all of those striving to achieve a single solution that is useful not only to those in the ARM ecosystem, but hopefully to other platform architectures as well.
Additional information about the overall effort described here can be found in the Office of the CTO section.
- Buffer object
- A piece of system or device memory, possibly including meta-data for bookkeeping purposes.
- Cache domain
- Buffer object meta-data indicating which device cache must be flushed/cleaned in order for a read operation by another device to yield a valid result.
- Marking a buffer object such that it will not change physical location.
- Image processing (display and/or manipulate picture being taken).
- Video recorders.
- Sound processing.
- DMA engines.
- GPU buffers.
- Display buffer.
For each of these spaces, there should be a general goal of eliminating most (e.g. all, but 2) of the options/solutions, generally in favor of existing upstream mechanisms. Possibly, existing solutions would need to be amended.
In-kernel IOMMU Mapping
- Existing interfaces
- Vendors with alternative solutions
- TI (OMAP)
User Buffer Mapping
Physical Memory Allocation
- Media Controller
map & unmap
- access control
- cache domain control
- Per-device cache domains; this includes the CPUs as well as all other hardware devices.
- Smart flushing/cleaning of device caches based upon domain change.
- It must be possible to share buffers between multiple hardware devices, drivers and userspace processes.
- The original creator of a buffer object must grant specific rights (read, write, map) to another process by ID; grants are revoked when PIDs are recycled.
- A buffer object, in particular its handle, should be resolvable from user space via a virtual address; normal access control rules still apply.
Physically contiguous allocations
- Must support physically contiguous allocations for those devices that need it (cameras, codecs).
- Other devices still get discontiguous allocations.
- Buffer objects should be reference-counted to avoid stale accesses due to in-flight transactions.
- Memory pool should be periodically de-fragmented.
- Analogous to the idea of what happens when a buffer object changes cache domains, a buffer object's storage could be changed from discontiguous to contiguous when moving from a device with an MMU to one without.
- Unpinned buffer objects can be swapped to storage.
- Buffer objects can be resized.
What devices actually require physically contiguous memory?
What to do about allocators that attempt to grab one large chunk early on (say, at boot time) and re-allocate from that (see: http://marc.info/?l=linux-mm&m=129416165500913&w=2)?
The following folks have been involved in e-mail threads that I have used for the basis of this page. I'm sure there are more, and am hoping there will be more as the discussion evolves. They don't necessarily think my summary herein is correct, and I hope they'll tell me where I'm wrong and where I've missed something.
- Robert Fekete
- Tom Cooksey
- Marcus Lorentzon
- Christian "Kiko" Reis
- David Airlie
- Jammy Zhou
- Arnd Bergmann
WorkingGroups/Middleware/Graphics/Projects/UnifiedMemoryManagement (last modified 2011-04-27 22:21:21)