lca14: lca14-509: ion upstreaming status & next steps
DESCRIPTION
Resource: LCA14 Name: LCA14-509: ION upstreaming status & next steps Date: 07-03-2014 Speaker: John Stultz and Sumit Semwal Video: https://www.youtube.com/watch?v=3ds_UJqX7mM Website: http://www.linaro.org/ Linaro Connect: http://connect.linaro.org/ Slide: https://www.slideshare.net/linaroorg/lca14-509-ionupstreamingstatusnextstepsTRANSCRIPT
John Stultz and Sumit Semwal, LCA14-509, Macau
ION: Next Steps
Background: What is ION
• Constraint aware* memory allocator• Different devices have different constraints on
what memory they can access• ION manages and provides a method of
allocating from different pools or types of memory, which will then be shared with various devices (via dma-bufs).
* “Aware” is maybe not quite accurate, but we’ll talk about that later
History
• Introduced into Android for ICS 3.0+ kernels• 32bit ARM only• Problematic DMA API usage• Very hardware-specific interface and implementations
• Summarized these and other issues on LWN• https://lwn.net/Articles/565469/• Thanks to Jesse and Arnd for help identifying these
problems• Synced with Android developers at Linux
Plumbers
• ION interface mostly used with graphics, which tend to be proprietary
• No access to drivers for testing with latest upstream kernels
• ARMv8 architecture models don’t even have gpu hardware available.
• Upstream graphics developers not fond of ION or Android’s approach to graphics
Difficulties
Since Linux Plumbers
• Colin Cross addressed most of the issues we pointed out, via heavy refactoring of the code.
• Colin also provided unit tests, which I’ve ported to non-android Linux environments
• Rom Lemarchand implemented compat_ioctl support
• Developed a dummy driver to allow for testing on systems that don’t have ION enabled graphics
• Worked with Colin to get the code tested and stabilized.
• Pushed the entire ION patchset upstream via staging (115+ patches).
Current Status
• ION builds and runs on ARM, x86_64, ARM64, etc.• Thanks to Jesse Barker for validating ARMv8!
• Compat ioctl support for 32bit applications running on 64bit kernels
• Working on getting ion unit tests integrated into lava.
Remaining issues
• ION still assumes phys addresses and bus addresses are the same.• This is ok on the hardware they care about so far.
• ION’s API requires userspace to manage the device-constraint to memory type mapping• Requires hardware specific gralloc userspace
• The types and subtleties of constraints is not easily enumerable, as they may be different device to device• ION uses heap-ids to specify memory types, but heap-ids
are often device specific.
Interface examplesfd = open(“/dev/ion”, O_RDONLY);struct ion_allocation_data data = { .len = len, .align = align, .heap_id_mask = heap_mask, .flags = flags, };
ret = ioctl(fd, ION_IOC_ALLOC, &data);Returns a buffer reference via: data.handle
Also:ION_IOC_FREE: Free allocated bufferION_IOC_MAP: Generates an fd that can be mmapedION_IOC_SHARE: Generates a dma-buf fd that can be shared
ION_IOC_IMPORT: Imports a dma-buf fdION_IOC_SYNC: Syncs the buffer to memory (deprecated)ION_IOC_CUSTOM: Heap specific ioctl multiplexer (ugh)
• dmabuf usage model:dma_buf_export()...dma_buf_get()dma_buf_attach()dma_buf_map_attachment()dma_buf_unmap_attachment()dma_buf_detach()dma_buf_put()
• dmabuf exporter doesn’t necessarily allocate backing buffer until map_attachment() time.
• When attaching, add device constraints to dmabuf, then when allocating at map time, use those constraints to allocate the right type of memory
What upstream developers want
• All devices have to have attached before the first map.• This can have permissions limitations, since process
starting things may not have permissions to access all the devices that may eventually use the buffer
• dmabuf exporters are all driver specific• Current dmabuf exporters don’t all use delayed (map
time) allocation.• Android developers unlikely to move from ION
• Don’t require generic solution, ok with device specific userland
• They like the directness of their approach
Issues with this approach
• Create a set of constraint aware dmabuf allocation helper functions
• Try to share code with ION by reusing the heaps• On dma_buf_attach(), store compatible heap
flags for that device in dma_buf• Provide helper functions that will look at heap
flags on dmabuf and allocate memory from the compatible ION heap
• Once we have common infrastructure, ION can be reduced to just a shim interface that provides the Android preferred semantics.
Plan
• Start looking at how to share the backing heap allocators with the map-time post-attach allocation that the dma-buf developers want to see.• Initially, we’ll do a PoC to prove ‘things work’• Two steps: Sharing constraints, and using allocator
helpers for dma-bufs
Next steps
Next steps
• Sharing constraints• add access_constraints_mask to dev->dma_parms of
importers• values for the mask are deliberately kept ‘open’ to allow use-
case / platform-driven definition• Then at each dma_buf_attach() call, check this mask for
attaching device and add to the global mask for the given dma_buf• error out if the new constraint causes the mask to become
zero => new device’s constraints won’t work with other devices in the use case
• At each dma_buf_detach() call, re-calculate global mask for the currently attached importers - this could help in backing storage migration if so desired by exporter.
• Allocation helpers for dma-buf• Central allocation helpers tied to dma-bufs - relevant only
when buffers are being shared around.• Used by dma-buf exporters to provide map-time backing-
storage allocation for each dma-buf• In the PoC, we intend to reuse the most common ION
heap functions for fixed ION constraint masks (heap masks); later, the design would be updated to allow adding custom allocation with function pointers and platform-specific constraint masks
Next steps
• New functionality in the usage sequence:dma_buf_get()- importer to set constraints in dev->dma_parms->access_constraints_mask
dma_buf_attach()- adds constraint to dma-buf; will return error if new device attachment doesn’t satisfy existing constraints
dma_buf_map_attachment()- exporter looks at constraint mask, and (optionally) uses allocation helpers to allocate
dma_buf_unmap_attachment()dma_buf_detach()- re-calculates dma-buf’s constraint maskdma_buf_put()
Next steps
• Dynamic handling of device specific heaps and dynamic heap priority
• Per-platform allocation policy• Separate from the constraint• Allows for preferring some dimms over others, contig memory in
special regions (secure playback), etc.• Likely per-platform and will need heap specific function pointer for
policy allocator.• Generic userland api
• Current dma-buf exporters are via per-device/subsystem ioctls (like drm/gem or v4l2).
• May be use for generic dma-buf exporter chardev?• Not yet handling some of the caching optimizations ION
uses, nor performance issues connected with proper dma-api usage w/ things like IOMMUs
Issues still to address
Links/Questions?• Constraints / allocator helper PoC current code:
https://git.linaro.org/people/sumit.semwal/linux-3.x.git• Areas of concern?• Does the constraint and policy split make sense?• Thoughts on enumeration theory?• Other possible consumers other than graphics?
• Networking?• eMMC / storage?• other?
More about Linaro Connect: http://connect.linaro.orgMore about Linaro: http://www.linaro.org/about/
More about Linaro engineering: http://www.linaro.org/engineering/Linaro members: www.linaro.org/members