+ All Categories
Home > Technology > LCA14: LCA14-509: ION upstreaming status & next steps

LCA14: LCA14-509: ION upstreaming status & next steps

Date post: 13-Jun-2015
Category:
Upload: linaro
View: 812 times
Download: 1 times
Share this document with a friend
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-ionupstreamingstatusnextsteps
Popular Tags:
18
John Stultz and Sumit Semwal, LCA14-509, Macau ION: Next Steps
Transcript
Page 1: LCA14: LCA14-509: ION upstreaming status & next steps

John Stultz and Sumit Semwal, LCA14-509, Macau

ION: Next Steps

Page 2: LCA14: LCA14-509: ION upstreaming status & 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

Page 3: LCA14: LCA14-509: ION upstreaming status & next steps

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

Page 4: LCA14: LCA14-509: ION upstreaming status & next steps

• 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

Page 5: LCA14: LCA14-509: ION upstreaming status & next steps

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).

Page 6: LCA14: LCA14-509: ION upstreaming status & next steps

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.

Page 7: LCA14: LCA14-509: ION upstreaming status & next steps

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.

Page 8: LCA14: LCA14-509: ION upstreaming status & next steps

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)

Page 9: LCA14: LCA14-509: ION upstreaming status & next steps

• 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

Page 10: LCA14: LCA14-509: ION upstreaming status & next steps

• 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

Page 11: LCA14: LCA14-509: ION upstreaming status & next steps

• 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

Page 12: LCA14: LCA14-509: ION upstreaming status & next steps

• 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

Page 13: LCA14: LCA14-509: ION upstreaming status & 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.

Page 14: LCA14: LCA14-509: ION upstreaming status & next steps

• 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

Page 15: LCA14: LCA14-509: ION upstreaming status & 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

Page 16: LCA14: LCA14-509: ION upstreaming status & 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

Page 17: LCA14: LCA14-509: ION upstreaming status & next steps

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?

Page 18: LCA14: LCA14-509: ION upstreaming status & next steps

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


Recommended