The Android ION memory allocator
- ION heaps
-
- ION设计的目标
- ION的实现
- user space ION API
- 在user space使用ION
-
- 使用场景
- 具体使用细节
- Demo
- 在kernel中share ION buffer
- kernel space ION API
-
- client申请与释放
- buffer申请及释放
- 地址映射
- 比较ION和DMABUF
- 参考
The Android ION memory allocator
英文原文
ION heaps
ION设计的目标
为了避免内存碎片化,或者为一些有着特殊内存需求的硬件,比如GPUs、display controller以及camera等,在系统启动的时候,会为他们预留一些memory pools,这些memory pools就由ION来管理。通过ION就可以在硬件以及user space之间实现zero-copy的内存share。
ION的实现
ION通过ION heaps来展示presents它对应的memory pools。不同的Android硬件可能会要求不同的ION heaps实现,默认的ION驱动会提供如下三种不同的ION heaps实现:
- ION_HEAP_TYPE_SYSTEM: memory allocated via vmalloc_user()
- ION_HEAP_TYPE_SYSTEM_CONTIG: memory allocated via kzalloc
- ION_HEAP_TYPE_CARVEOUT: carveout memory is physically contiguous and set aside at boot.
开发者可以自己实现更多的ION heaps。比如NVIDIA就提交了一种ION_HEAP_TYPE_IOMMU的heap,这种heap带有IOMMU功能。
不管哪一种ION heaps实现,他们都必须实现如下接口:
struct ion_heap_ops {
int (*allocate) (struct ion_heap *heap,
struct ion_buffer *buffer, unsigned long len,
unsigned long align, unsigned long flags);
void (*free) (struct ion_buffer *buffer);
int (*phys) (struct ion_heap *heap, struct ion_buffer *buffer,
ion_phys_addr_t *addr, size_t *len);
struct scatterlist *(*map_dma) (struct ion_heap *heap,
struct ion_buffer *buffer);
void (*unmap_dma) (struct ion_heap *heap,
struct ion_buffer *buffer);
void * (*map_kernel) (struct ion_heap *heap,
struct ion_buffer *buffer);
void (*unmap_kernel) (struct ion_heap *heap,
struct ion_buffer *buffer);
int (*map_user) (struct ion_heap *heap, struct ion_buffer *buffer,
struct vm_area_struct *vma);
};
简单来说,接口的各个函数功能如下:
- allocate()和free()分别用来从heap中分配或者释放一个ion_buffer对象对于物理连续的内存。
- phys()用来得到ion_buffer对象的物理内存地址及其大小。如果heap没有提供物理连续的内存,那么它也可以不用提供这个接口。其中,ion_phys_addr_t将来会被定义在/include/linux/types.h中的phys_addr_t替代。
- map_dma()和unmap_dma()分别来用使ion_buffer对象为DMA(Direct Memory Access,直接内存存取。顾名思义,不占用cpu资源,从一个硬件存储区域把一部分连续的数据复制到另一个硬件存储区域)做好准备或者取消做好准备
- map_kernel()和unmap_kernel()分别用来把physical memory映射(map)到内核虚拟地址空间(kernel virtual address space)或者取消映射
- map_user()用来把physical memory映射(map)到用户内存空间(user space)。为什么没有对应的unmap_user()呢?因为,这个映射用一个file descriptor来表示,当这个file descriptor关闭的时候,这个映射关系就自动取消了。
user space ION API
定义了6种 ioctl 接口,可以与用户应用程序交互。
- ION_IOC_ALLOC: 分配内存
- ION_IOC_FREE: 释放内存
- ION_IOC_MAP: 获取文件描述符进行mmap
- ION_IOC_SHARE: 创建文件描述符来实现共享内存
- ION_IOC_IMPORT: 获取文件描述符
- ION_IOC_CUSTOM: 调用用户自定义的ioctl
ION_IOC_SHARE 及ION_IOC_IMPORT是基于DMABUF实现的,所以当共享进程获取文件描述符后,可以直接调用mmap来操作共享内存。mmap实现由DMABUF子系统调用ION子系统中mmap回调函数完成。
在user space使用ION
使用场景
典型的,在用户空间使用的设备访问库(user space device access libraries)一般使用ION来分配大块连续的media buffers。比如,still camera library分配一个capture buffer来供camera device使用。当这个buffer填满video data的时候,这个library就能把这块buffer传递给kernel,然后让JPEG硬编码模块来处理。
具体使用细节
在user space 的C/C++程序能够能够分配ION内存之前,它必须获得访问/dev/ion的权限。通过调用
open("/dev/ion", O_RDONLY)
就可获得一个以handle形式返回的file descriptor,这个file descriptor用来代表一个ION client。注意,虽然传给open一个O_RDONLY参数,但是你仍然可对这块memory进行写操作。在一个user process中最多有一个client。当有了一个client之后,就可以开始分配ION内存。为了分配内存,client必须填满下面的ion_allocation_data结构,handle除外,因为它是output参数。其他三个参数分别指明内存的大小、对齐方式以及flags。flags是一个bit mask,用来说明可以从哪些heaps中分配想要的内存。其决定顺序由系统启动时,通过ion_device_add_heap()添加的heap顺来决定。比如,ION_HEAP_TYPE_CARVEOUT是在ION_HEAP_TYPE_CONTIG之前被add的,那么如果flags = ION_HEAP_TYPE_CONTIG | ION_HEAP_TYPE_CARVEOUT,那么就是先尝试分配ION_HEAP_TYPE_CARVEOUT类型的heap,如果不行,再尝试分配ION_HEAP_TYPE_CONTIG类型的heap。()
struct ion_allocation_data {
size_t len;
size_t align;
unsigned int flags;
struct ion_handle *handle;
}
user space通过ioctl()系统接口来与ION交互。在client填充ion_allocatoin_data结构之后,就可以通过调用
int ioctl(int client_fd, ION_IOC_ALLOC, struct ion_allocation_data *allocation_data)
来allocate a buffer。这个调用介绍之后,分配的buffer会通过ion_allocatoin_data的handle来返回,但是CPU不可以访问这个buffer。这个handle只可以通过调用int ioctl(int client_fd, ION_IOC_SHARE, struct ion_fd_data *fd_data);来获得一个用来share的file descriptor。这里,client_fd参数是前面通过open获得的一个对应/dev/ion file descriptor,fd_data是如下的数据结构,其handle对应ion_allocation_data::handle,是input参数;fd则是output参数,可以用来share。
当一个user process中的client分享(share)了这个fd之后,在其他user process中(当然,也可share给创建这个fd的client自己),为了获得这个shared buffer,先必须通过调用open("/dev/ion", O_RDONLY)获得一个client。(注:ION通过线程的PID来track各个client, 尤其是process中的"group leader"线程的PID。在相同的process中重复调用open("/dev/ion", O_RDONLY)只会获得指向kernel同一个client的another file descriptor)。获得client之后,然后再通过mmap()函数来把这个fd映射到address space of process(mmap函数参考1,参考2)。如果要释放这个fd对应的buffer,在调用mmap()的process中,先要通过munmap()来取消mmap()的效果。然后在之前share这个fd的client中,需要通过int ioctl(int client_fd, ION_IOC_FREE, struct ion_handle_data *handle_data);来关闭这个fd对应的file descriptor。其中,ion_handle_data表示前面通过ION_IOC_ALLOC命令获得的handle,其定义如下:
struct ion_handle_data {
struct ion_handle *handle;
}
这个ION_IOC_FREE命令会导致对应的handle的计数减1。当handle计数为0的时候,其指向的ion_handle对象就会被销毁,并且相关的ION bookkeeping数据结构也会更新。
Demo
在这个Demo中,fd在同一个client中被share使用:
#include<stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
#include "/home/developer/kernel3.4/goldfish/include/linux/ion.h"
void main()
{
struct ion_fd_data fd_data;
struct ion_allocation_data ionAllocData;
ionAllocData.len=0x1000;
ionAllocData.align = 0;
ionAllocData.flags = ION_HEAP_TYPE_SYSTEM;
int fd=open("/dev/ion",O_RDWR);
ioctl(fd,ION_IOC_ALLOC, &ionAllocData);
fd_data.handle = ionAllocData.handle;
ioctl(fd,ION_IOC_SHARE,&fd_data);
int *p = mmap(0,0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd_data.fd,0);
p[0]=99;
perror("test");
printf("hello all %d\n",p[0]);
}
在kernel中share ION buffer
在kernel中支持multiple clients,每一个使用ION功能的driver都可以在kernel中对应一个client。一个kernel driver通过调用struct ion_client *ion_client_create(struct ion_device *dev, unsigned int heap_mask, const char *debug_name)来获得一个ION client handle(注意,前面在user space中通过open("/dev/ion", O_RDONLY)返回的client是int类型)。dev参数是一个和/dev/ion相关的global ION device,heap_mask参数和之前提到的ion_allocation_data的flags成员一样的含义。
当在user space中通过ION_IOC_SHARE命令得到一个buffer的file descriptor并把它传递给kernel之后,kernel driver通过调用struct ion_handle *ion_import_fd(struct ion_client *client, int fd_from_user);来把这个fd变成一个ion_handle对象,这个对象就是这个driver中对相应的buffer一个client-local reference。ion_import_fd方法会根据这个buffer的物理地址来查找:在本client中是否已经obtained一个对应此buffer的ion_handle,如果是的话,那么就可以简单的增加这个ion_handle的引用计数即可。
有些硬件只能通过physical addresses来操作physically-contiguous buffers,那么,这些对应的drivers就需要通过调用int ion_phys(struct ion_client *client, struct ion_handle *handle, ion_phys_addr_t *addr, size_t *len)来把ion_handle转变成一个physical buffer。当然,如果这个buffer不是physically contiguous,那么这个调用就会失败。
当处理一个来自client的调用时,ION会validates 输入的 file descriptor, client and handle arguments。比如ION会确保 file descriptor是由ION_IOC_SHARE命令创建的;比如当ion_phys()调用时,ION会检测这个buffer是否在这个client对应有访问权限list中,如果不是,那么就会返回错误。这样的验证机制能够减少可能的unwanted accesses以及疏忽的内存泄露。
ION通过debugfs提供可视化的debug,它通过在/sys/kernel/debug/ion下面,使用stored files来记录相应的heaps和clients,并使用symbolic names或者PIDs来标志。
kernel space ION API
内核驱动也可以注册为一个ION的客户端(client),可以选择使用哪种类型的heap来申请内存。
client申请与释放
- ion_client_create: 分配一个客户端。
- ion_client_destroy: 释放一个客户端及绑定在它上面的所有ion handle.
ion handle: 这里每个ion handle映射到一个buffer中,每个buffer关联一个heap。也就是说一个客户端可以操作多块buffer。
buffer申请及释放
- ion_alloc: 申请ion内存,返回ion handle
- ion_free: 释放ion handle
地址映射
ION 通过handle来管理buffer,驱动需要可以访问到buffer的地址。ION通过下面的函数来达到这个目的
- ion_phys: 返回buffer的物理地址(address)及大小(size)
- ion_map_kernel: 给指定的buffer创建内核内存映射
- ion_unmap_kernel: 销毁指定buffer的内核内存映射
- ion_map_dma: 为指定buffer创建dma 映射,返回sglist(scatter/gather list)
- ion_unmap_dma: 销毁指定buffer的dma映射
ION是通过handle而非buffer地址来实现驱动间共享内存,用户空间共享内存也是利用同样原理。
- ion_share: given a handle, obtain a buffer to pass to other clients
- ion_import: given an buffer in another client, import it
- ion_import_fd: given an fd obtained via ION_IOC_SHARE ioctl, import it
ION_IOC_SHARE 及ION_IOC_IMPORT是基于DMABUF实现的,所以当共享进程获取文件描述符后,可以直接调用mmap来操作共享内存。mmap实现由DMABUF子系统调用ION子系统中mmap回调函数完成。
比较ION和DMABUF
本节部分翻译。
- ION和DMABUF都是通过传递一个匿名file descriptor对象,给其他client一个基于引用计数的访问权限,从而达到分享内存的目的。
- ION通过一个可分享和追踪的方式从预留的memory pool中分配内存。
- DMABUF更多的专注于buffer导入、导出以及同步的方式来实现在NON-ARM架构上的buffer的分享。
- ION目前只支持Android kernel
- ION所有的user-space program都可以通过/dev/ion接口来分配ION内存。但是在Android会通过验证user和group IDs的方式来阻止对ION的非授权访问。
参考
https://www.cnblogs.com/willhua/p/10029280.html
https://blog.csdn.net/armwind/article/details/53454251
https://blog.csdn.net/av_geek/article/details/47664505