Jimmy Chen

A Programmer

(转载)Android系统匿名共享内存Ashmem(Anonymous Shared Memory)驱动程序源代码分析

  PS:最近在学习surfaceflinger和hardwarecomposer的内容,这中间有用到匿名共享内存的知识,所以就从老罗的博客中转载这篇博客作为备份学习了。

  在上一文章Android系统匿名共享内存Ashmem(Anonymous Shared Memory)简要介绍和学习计划中,我们简要介绍了Android系统的匿名共享内存机制,其中,简要提到了它具有辅助内存管理系统来有效地管理内存的特点,但是没有进一步去了解它是如何实现的。在本文中,我们将通过分析Android系统的匿名共享内存Ashmem驱动程序的源代码,来深入了解它是如何辅助内存管理系统

  Android系统的匿名共享内存Ashmem机制并没有自立山头,从头搞一套自己的共享内存机制,而是建立在Linux内核实现的共享内存的基础上的。与此同时,它又向Linux内存管理系统的内存回收算法注册接口,告诉Linux内存管理系统它的某些内存块不再使用了,可以被回收了,不过,这些不再使用的内存需要由它的使用者来告诉Ashmem驱动程序。通过这种用户-Ashmem驱动程序-内存管理系统三者的紧密合作,实现有效的内存管理机制,适合移动设备小内存的特点。

  Android系统的匿名共享内存Ashmem驱动程序利用了Linux的共享内存子系统导出的接口来实现自己的功能,因此,它的实现非常小巧,总共代码不到700行。虽然代码很少,但是这里不打算机械式地一行一行地阅读和分析Ashmem驱动程序的源代码,而是通过使用情景来分析,这样可以帮助我们清晰地理解它的实现原理。我们这里所说的使用情景,将从Android系统的应用程序框架层提供的匿名共享内存接口开始,经过系统运行时库层,最终到达驱动程序层,通过这样一个完整的过程来理解Android系统的匿名共享内存Ashmem机制。这里,我们将从上一篇文章Android系统匿名共享内存Ashmem(Anonymous Shared Memory)简要介绍和学习计划介绍的Android应用程序框架层提供MemoryFile接口开始,分别介绍Android系统匿名共享内存的创建(open)、映射(mmap)、读写(read/write)以及锁定和解锁(pin/unpin)四个使用情景。

  在进入到这个四个使用情景前,我们先来看一下Ashmem驱动程序模块的初始化函数,看看它给用户空间暴露了什么接口,即它创建了什么样的设备文件,以及提供了什么函数来操作这个设备文件。Ashmem驱动程序实现在kernel/common/mm/ashmem.c文件中,它的模块初始化函数定义为ashmem_init:

  这里,我们可以看到,Ahshmem驱动程序在加载时,会创建一个/dev/ashmem的设备文件,这是一个misc类型的设备。注册misc设备是通过misc_register函数进行的,关于这个函数的详细实现,可以参考前面Android日志系统驱动程序Logger源代码分析一文,调用这个函数成功后,就会在/dev目录下生成一个ashmem设备文件了。同时,我们还可以看到,这个设备文件提供了open、mmap、release和ioctl四种操作。为什么没有read和write操作呢?这是因为读写共享内存的方法是通过内存映射地址来进行的,即通过mmap系统调用把这个设备文件映射到进程地址空间中,然后就直接对内存进行读写了,不需要通过read 和write文件操作,后面我们将会具体分析是如何实现的。

  有了这个基础之后,下面我们就分四个部分来分别介绍匿名共享内存的创建(open)、映射(mmap)、读写(read/write)以及锁定和解锁(pin/unpin)使用情景。

一. 匿名共享内存的创建操作

  在Android应用程序框架层提供MemoryFile类的构造函数中,进行了匿名共享内存的创建操作,我们先来看一下这个构造函数的实现,它位于frameworks/base/core/java/android/os/MemoryFile.java文件中:

  这里我们看到,这个构造函数最终是通过JNI方法native_open来创建匿名内存共享文件。这个JNI方法native_open实现在frameworks/base/core/jni/adroid_os_MemoryFile.cpp文件中:

  这个函数又通过运行时库提供的接口ashmem_create_region来创建匿名共享内存,这个函数实现在system/core/libcutils/ashmem-dev.c文件中:

  这里,一共通过执行三个文件操作系统调用来和Ashmem驱动程序进行交互,分别是一个open和两个ioctl操作,前者是打开设备文件ASHMEM_DEVICE,后者分别是设置匿名共享内存的名称和大小。

  在介绍这三个文件操作之前,我们先来了解一下Ashmem驱动程序的一个相关数据结构struct ashmem_area,这个数据结构就是用来表示一块共享内存的,它定义在kernel/common/mm/ashmem.c文件中:

  域name表示这块共享内存的名字,这个名字会显示/proc//maps文件中,表示打开这个共享内存文件的进程ID;域unpinned_list是一个列表头,它把这块共享内存中所有被解锁的内存块连接在一起,下面我们讲内存块的锁定和解锁操作时会看到它的用法;域file表示这个共享内存在临时文件系统tmpfs中对应的文件,在内核决定要把这块共享内存对应的物理页面回收时,就会把它的内容交换到这个临时文件中去;域size表示这块共享内存的大小;域prot_mask表示这块共享内存的访问保护位。

  在Ashmem驱动程中,所有的ashmem_area实例都是从自定义的一个slab缓冲区创建的。这个slab缓冲区是在驱动程序模块初始化函数创建的,我们来看一个这个初始化函数的相关实现:

  全局变量定义在文件开头的地方:

  它的类型是struct kmem_cache,表示这是一个slab缓冲区,由内核中的内存管理系统进行管理。

  这里就是通过kmem_cache_create函数来创建一个名为”ashmem_area_cache”、对象大小为sizeof(struct ashmem_area)的缓冲区了。缓冲区创建了以后,就可以每次从它分配一个struct ashmem_area对象了。关于Linux内核的slab缓冲区的相关知识,可以参考前面Android学习启动篇一文中提到的一本参考书籍《Understanding the Linux Kernel》的第八章Memory Managerment

  有了这些基础知识后,我们回到前面的ashmem_create_region函数中。

  首先是执行打开文件的操作:

  ASHMEM_DEVICE是一个宏,定义为:

  这里就是匿名共享内存设备文件/dev/ashmem了。

  从上面的描述我们可以知道,调用这个open函数最终会进入到Ashmem驱动程序中的ashmem_open函数中去:

  首先是通过nonseekable_open函数来设置这个文件不可以执行定位操作,即不可以执行seek文件操作。接着就是通过kmem_cache_zalloc函数从刚才我们创建的slab缓冲区ashmem_area_cachep来创建一个ashmem_area结构体了,并且保存在本地变量asma中。再接下去就是初始化变量asma的其它域,其中,域name初始为ASHMEM_NAME_PREFIX,这是一个宏,定义为:

  函数的最后是把这个ashmem_area结构保存在打开文件结构体的private_data域中,这样,Ashmem驱动程序就可以在其它地方通过这个private_data域来取回这个ashmem_area结构了。

  到这里,设备文件/dev/ashmem的打开操作就完成了,它实际上就是在Ashmem驱动程序中创建了一个ashmem_area结构,表示一块新的共享内存。

  再回到ashmem_create_region函数中,又调用了两次ioctl文件操作分别来设备这块新建的匿名共享内存的名字和大小。在kernel/comon/mm/include/ashmem.h文件中,ASHMEM_SET_NAME和ASHMEM_SET_SIZE的定义为:

  先来看ASHMEM_SET_NAME命令的ioctl调用,它最终进入到Ashmem驱动程序的ashmem_ioctl函数中:

  这里通过set_name函数来进行实际操作:

  这个函数实现很简单,把用户空间传进来的匿名共享内存的名字设置到asma->name域中去。注意,匿名共享内存块的名字的内容分两部分,前一部分是前缀,这是在open操作时,由驱动程序默认设置的,固定为ASHMEM_NAME_PREFIX,即”dev/ashmem/”;后一部分由用户指定,这一部分是可选的,即用户可以不调用ASHMEM_SET_NAME命令来设置匿名共享内存块的名字。

  再来看ASHMEM_SET_SIZE命令的ioctl调用,它最终也是进入到Ashmem驱动程序的ashmem_ioctl函数中:

  这个实现很简单,只是把用户空间传进来的匿名共享内存的大小值保存在对应的asma->size域中。

  这样,ashmem_create_region函数就执先完成了,层层返回,最后回到应用程序框架层提供的接口Memory的构造函数中,整个匿名共享内存的创建过程就完成了。前面我们说过过,Ashmem驱动程序不提供read和write文件操作,进程若要访问这个共享内存,必须要把这个设备文件映射到自己的进程空间中,然后进行直接内存访问,这就是我们下面要介绍的匿名共享内存设备文件的内存映射操作了。

二. 匿名共享内存设备文件的内存映射操作

  在MemoryFile类的构造函数中,进行了匿名共享内存的创建操作后,下一步就是要把匿名共享内存设备文件映射到进程空间来了:

  映射匿名共享内存设备文件到进程空间是通过JNI方法native_mmap来进行的。这个JNI方法实现在frameworks/base/core/jni/adroid_os_MemoryFile.cpp文件中:

  这里的文件描述符fd是在前面open匿名设备文件/dev/ashmem获得的,有个这个文件描述符后,就可以直接通过mmap来执行内存映射操作了。这个mmap系统调用最终进入到Ashmem驱动程序的ashmem_mmap函数中:

  这个函数的实现也很简单,它调用了Linux内核提供的shmem_file_setup函数来在临时文件系统tmpfs中创建一个临时文件,这个临时文件与Ashmem驱动程序创建的匿名共享内存对应。函数shmem_file_setup是Linux内核中用来创建共享内存文件的方法,而Linux内核中的共享内存机制其实是一种进程间通信(IPC)机制,它的实现相对也是比较复杂,Android系统的匿名共享内存机制正是由于直接使用了Linux内核共享内存机制,它才会很小巧,它站在巨人的肩膀上了。关于Linux内核中的共享内存的相关知识,可以参考前面Android学习启动篇一文中提到的一本参考书籍《Linux内核源代码情景分析》的第六章传统的Unix进程间通信第七小节共享内存。

  通过shmem_file_setup函数创建的临时文件vmfile最终就保存在vma->file中了。这里的vma是由Linux内核的文件系统层传进来的,它的类型为struct vm_area_struct,它表示的是当前进程空间中一块连续的虚拟地址空间,它的起始地址可以由用户来指定,也可以由内核自己来分配,这里我们从JNI方法native_mmap调用的mmap的第一个参数为NULL可以看出,这块连续的虚拟地址空间的起始地址是由内核来指定的。文件内存映射操作完成后,用户访问这个范围的地址空间就相当于是访问对应的文件的内容了。有关Linux文件的内存映射操作,同样可以参考前面Android学习启动篇一文中提到的一本参考书籍《Linux内核源代码情景分析》的第二章内存管理第十三小节系统调用mmap。从这里我们也可以看出,Android系统的匿名共享内存是在虚拟地址空间连续的,但是在物理地址空间就不一定是连续的了

  同时,这个临时文件vmfile也会保存asma->file域中,这样,Ashmem驱动程序后面就可以通过在asma->file来操作这个匿名内存共享文件了。

  函数ashmem_mmap执行完成后,经过层层返回到JNI方法native_mmap中去,就从mmap函数的返回值中得到了这块虚拟空间的起始地址了,这个起始地址最终返回到应用程序框架层的MemoryFile类的构造函数中,并且保存在成员变量mAddress中,后面,共享内存的读写操作就是对这个地址空间进行操作了。

三. 匿名共享内存的读写操作

  因为前面对匿名共享内存文件进行内存映射操作,这里对匿名内存文件内容的读写操作就比较简单了,就像访问内存变量一样就行了。

  我们来看一下MemoryFile类的读写操作函数:

  这里,我们可以看到,MemoryFile的匿名共享内存读写操作都是通过JNI方法来实现的,读操作和写操作的JNI方法分别是native_read和native_write,它们都是定义在frameworks/base/core/jni/adroid_os_MemoryFile.cpp文件中:

  这里的address参数就是我们在前面执行mmap来映射匿名共享内存文件到内存中时,得到的进程虚拟地址空间的起始地址了,因此,这里就直接可以访问,不必进入到Ashmem驱动程序中去,这也是为什么Ashmem驱动程序没有提供read和write文件操作的原因。

  这里我们看到的ashmem_pin_region和ashmem_unpin_region两个函数是系统运行时库提供的接口,用来执行我们前面说的匿名共享内存的锁定和解锁操作,它们的作用是告诉Ashmem驱动程序,它的哪些内存块是正在使用的,需要锁定,哪些内存是不需要使用了,可以它解锁,这样,Ashmem驱动程序就可以辅助内存管理系统来有效地管理内存了。下面我们就看看Ashmem驱动程序是如果辅助内存管理系统来有效地管理内存的。

四. 匿名共享内存的锁定和解锁操作

  前面提到,Android系统的运行时库提到了执行匿名共享内存的锁定和解锁操作的两个函数ashmem_pin_region和ashmem_unpin_region,它们实现在system/core/libcutils/ashmem-dev.c文件中:

  它们的实现很简单,通过ASHMEM_PIN和ASHMEM_UNPIN两个ioctl操作来实现匿名共享内存的锁定和解锁操作。

  我们先看来一下ASHMEM_PIN和ASHMEM_UNPIN这两个命令号的定义,它们的定义可以在kernel/common/include/linux/ashmem.h文件中找到:

  它们的参数类型为struct ashmem_pin,它也是定义在kernel/common/include/linux/ashmem.h文件中:

  这个结构体只有两个域,分别表示要锁定或者要解锁的内块的起始大小以及大小。

  在分析这两个操作之前,我们先来看一下Ashmem驱动程序中的一个数据结构struct ashmem_range,这个数据结构就是用来表示某一块被解锁(unpinnd)的内存:

  域asma表示这块被解锁的内存所属于的匿名共享内存,它通过域unpinned连接在asma->unpinned_list表示的列表中;域pgstart和paend表示这个内存块的开始和结束页面号,它们表示一个前后闭合的区间;域purged表示这个内存块占用的物理内存是否已经被回收;这块被解锁的内存块除了保存在它所属的匿名共享内存asma的解锁列表unpinned_list之外,还通过域lru保存在一个全局的最近最少使用列表ashmem_lru_list列表中,它的定义如下:

  了解了这个数据结构之后,我们就可以来看ashmem_ioctl函数中关于ASHMEM_PIN和ASHMEM_UNPIN的操作了:

  它们都是通过ashmem_pin_unpin来进一步处理:

  首先是获得用户空间传进来的参数,并保存在本地变量pin中,这是一个struct ashmem_pin类型的变量,这个结构体我们在前面已经见过了,它包括了要pin/unpin的内存块的起始地址和大小,这里的起始地址和大小都是以字节为单位的,因此,通过转换把它们换成以页面为单位的,并且保存在本地变量pgstart和pgend中。这里除了要对参数作一个安全性检查外,还要一个处理逻辑是,如果从用户空间传进来的内块块的大小值为0 ,则认为是要pin/unpin整个匿名共享内存。

  函数最后根据当前要执行的是ASHMEM_PIN操作还是ASHMEM_UNPIN操作来分别执行ashmem_pin和ashmem_unpin来进一步处理。创建匿名共享内存时,默认所有的内存都是pinned状态的,只有用户告诉Ashmem驱动程序要unpin某一块内存时,Ashmem驱动程序才会把这块内存unpin,之后,用户可以再告诉Ashmem驱动程序要重新pin某一块之前被unpin过的内块,从而把这块内存从unpinned状态改为pinned状态,也就是说,执行ASHMEM_PIN操作时,目标对象必须是一块当前处于unpinned状态的内存块。

  我们先来看一下ASHMEM_UNPIN操作,进入到ashmem_unpin函数:

  这个函数的主体就是在遍历asma->unpinned_list列表,从中查找当前处于unpinned状态的内存块是否与将要unpin的内存块[pgstart, pgend]是否相交,如果相交,则要执行合并操作,即调整pgstart和pgend的大小,然后通过调用range_del函数删掉原来的已经被unpinned过的内存块,最后再通过range_alloc函数来重新unpinned这块调整过后的内存块[pgstart, pgend],这里新的内存块[pgstart, pgend]已经包含了刚才所有被删掉的unpinned状态的内存。注意,这里如果找到一块相并的内存块,并且调整了pgstart和pgend的大小之后,要重新再扫描一遍asma->unpinned_list列表,因为新的内存块[pgstart, pgend]可能还会与前后的处于unpinned状态的内存块发生相交。

  我们来看一下range_before_page的操作,这是一个宏定义:

  表示range描述的内存块是否在page页面之前,如果是,则整个描述就结束了。从这里我们可以看出asma->unpinned_list列表是按照页面号从大到小进行排列的,并且每一块被unpin的内存都是不相交的。

   再来看一下page_range_subsumed_by_range的操作,这也是一个宏定义:

  表示range描述的内存块是不是包含了[start, end]这个内存块,如果包含了,则说明当前要unpin的内存块已经处于unpinned状态,什么也不用操作,直接返回即可。

  再看page_range_in_range的操作,它也是一个宏定义:

  它用到的其它两个宏分别定义为:

  它们都是用来判断两个内存区间是否相交的。

  两个内存块相交分为四种情况:

  第一种情况,前面已经讨论过了,对于第二到第四种情况,都是需要执行合并操作的。

   再来看从asma->unpinned_list中删掉内存块的range_del函数:

  这个函数首先把range从相应的unpinned_list列表中删除,然后判断它是否在lru列表中:

  如果它的状态purged等于ASHMEM_NOT_PURGED,即对应的物理页面尚未被回收,它就位于lru列表中,通过调用lru_del函数进行删除:

  最后调用kmem_cache_free将它从slab缓冲区ashmem_range_cachep中释放。

  这里的slab缓冲区ashmem_range_cachep定义如下:

  它和前面介绍的slab缓冲区ashmem_area_cachep一样,是在Ashmem驱动程序模块初始化函数ashmem_init进行初始化的:

  回到ashmem_unpin函数中,我们再来看看range_alloc函数的实现:

  这个函数的作用是从slab 缓冲区中ashmem_range_cachep分配一个ashmem_range,然后对它作相应的初始化,放在相应的ashmem_area->unpinned_list列表中,并且还要判断这个range的purged是否是ASHMEM_NOT_PURGED状态,如果是,还要把它放在lru列表中:

  这样,ashmem_unpin的源代码我们就分析完了。

  接着,我们再来看一下ASHMEM_PIN操作,进入到ashmem_pin函数:

  前面我们说过,被pin的内存块,必须是在unpinned_list列表中的,如果不在,就什么都不用做。要判断要pin的内存块是否在unpinned_list列表中,又要通过遍历相应的asma->unpinned_list列表来找出与之相交的内存块了。这个函数的处理方法大体与前面的ashmem_unpin函数是一致的,也是要考虑四种不同的相交情况,这里就不详述了,读者可以自己分析一下。

  这里我们只看一下range_shrink函数的实现:

  这个函数的实现很简单,只是调整一下range描述的内存块的起始页面号,如果它是位于lru列表中,还要调整一下在lru列表中的总页面数大小。

  这样,匿名共享内存的ASHMEM_PIN和ASHMEM_UNPIN操作就介绍完了,但是,我们还看不出来Ashmem驱动程序是怎么样辅助内存管理系统来有效管理内存的。有了前面这些unpinned的内存块列表之后,下面我们就看一下Ashmem驱动程序是怎么样辅助内存管理系统来有效管理内存的。

  首先看一下Ashmem驱动程序模块初始化函数ashmem_init:

  这里通过调用register_shrinker函数向内存管理系统注册一个内存回收算法函数。在Linux内核中,当系统内存紧张时,内存管理系统就会进行内存回收算法,将一些最近没有用过的内存换出物理内存去,这样可以增加物理内存的供应。因此,当内存管理系统进行内存回收时,就会调用到这里的ashmem_shrink函数,让Ashmem驱动程序执行内存回收操作:

  这里的参数nr_to_scan表示要扫描的页数,如果是0,则表示要查询一下,当前Ashmem驱动程序有多少页面可以回收,这里就等于挂在lru列表的内块页面的总数了,即lru_count;否则,就要开始扫描lru列表,从中回收内存了,直到回收的内存页数等于nr_to_scan,或者已经没有内存可回收为止。回收内存页面是通过vm_truncate_range函数进行的,这个函数定义在kernel/common/mm/memory.c文件中,它是Linux内核内存管理系统实现的,有兴趣的读者可以研究一下。

  这样,Android系统匿名共享内存Ashmem驱动程序源代码就分析完了,在下一篇文章中,我们将继续分析Android系统的匿名共享内存机制,研究它是如何通过Binder进程间通信机制实现在不同进程程进行内存共享的,敬请关注。

转载自:https://blog.csdn.net/luoshengyang/article/details/6664554

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据

%d 博主赞过: