Binder驱动之Buffer Size

三个传输空间限制

Android中，由Zygote孵化的进程是通过ProcessState来创建Binder实体的。实体创建过程中会映射一段内存空间用于数据传输，其大小设置为 ((1*1024*1024) - (4096*2))。

    1.---> ProcessState.cpp 
    2.  
    3. #define BINDER_VM_SIZE ((1*1024*1024) - (4096 *2))
    4. . . . . . .
    5.ProcessState::ProcessState()
    6.    : mDriverFD(open_driver()) // 打开了Binder设备
    7.    , mVMStart(MAP_FAILED) // 内存映射的真实地址
    8.    , mManagesContexts(false)
    9.    , mBinderContextCheckFunc(NULL)
    10.    , mBinderContextUserData(NULL)
    11.    , mThreadPoolStarted(false)
    12.    , mThreadPoolSeq(1)
    13.{
    14.    if (mDriverFD >= 0) {
    15.        // 对Binder设备进行内存映射
    16.        mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);
    17.        if (mVMStart == MAP_FAILED) {
    18.            close(mDriverFD);
    19.            mDriverFD = -1;
    20.        }
    21.    }
    22.}

在Binder机制中，有一个非常特殊的Service，就是Service Manager。它做为Binder机制的守护进程，管理着其他的Services。它的Binder buffer大小也不同，为(128*1024)。因为它只是用于管理services，提供addServcie，getService等功能，所以不会涉及大数据传输，因为没有分配较大的传输空间。

    1.---> service_manager.c
    2.  
    3.int main(int argc, char **argv)
    4.{
    5.    struct binder_state *bs;
    6.
    7.    bs = binder_open(128*1024);
    8.    ......
    9.}

Kernel中对Binder传输的大小也有个限制，大小为4M。这个限制使得所有的应用都无法申请大于4M的传输空间。

    1.---> binder.c
    2.  
    3.static int binder_mmap(struct file *filp, struct vm_area_struct *vma)
    4.{
    5.    ......
    6.    if ((vma->vm_end - vma->vm_start) > SZ_4M)
    7.        vma->vm_end = vma->vm_start + SZ_4M;
    8.    ......
    9.    proc->buffer_size = vma->vm_end - vma->vm_start;
    10.    ......
    11.    proc->free_async_space = proc->buffer_size / 2;
    12.    ....
    13.}

目前，我们得到的三个对Binder传输空间的限制。

• (128*1024)：对Service Manager的限制。
• ((1*1024*1024) - (4096 *2))：对普通Android services的限制。
• 4M：kernel可以接受的最大空间。

所以，实际应用可以申请的最大Binder Buffer是4M。但考虑实际传输的需要和节省内存，Android中申请的是(1M - 8K)。这个值是可以增加的，只要不大于4M就可以。

1M - 8K

Binder Buffer为什么会是(1M - 8K)，二不是整数值1M？这里看起来很奇怪，8K空间到底时用来做什么的？从GIT提交的记录可以看到下面的commits。

Modify the binder to request 1M - 2 pages instead of 1M. The backing store in the kernel requires a guard page, so 1M allocations fragment memory very badly. Subtracting a couple of pages so that they fit in a power of two allows the kernel to make more efficient use of its virtual address space.

这段解释还没有充分理解，其大致的意思是：kernel的“backing store”需要一个保护页，这使得1M用来分配碎片内存时变得很差，所以这里减去两页来提高效率，因为减去一页就变成了奇数。至于保护页如何影响内存分配，需要后续分析内存管理时再进一步研究。

同步和异步

Binder通信可以分为同步传输和异步传输，在设置传输空间大小时，将异步传输空间设置为同步传输的一半。
proc->free_async_space = proc->buffer_size / 2;
Binder通过红黑树进行buffer管理，将分配使用的buffer放入 allocated_buffers，将回收的buffer放入free_buffers。无论同步还是异步，这里的操作都是相同的。

    1.---> binder.c
    2. 
    3.struct binder_proc {
    4.    ......
    5.    struct list_head buffers;
    6.    struct rb_root free_buffers;
    7.    struct rb_root allocated_buffers;
    8.    size_t free_async_space;
    9.    ......
    10.}

而free_async_space只是用来统计异步传输时已经分配了多少空间。初始化时将其设置为全部buffer空间的一半，更多的是想对异步传输做一个限制，不希望异步传输消耗掉所有的buffer。相比较而言，同步传输可能会承载更重要的数据，应该尽量保证同步传输有可用buffer。并且异步传输是不需要等待返回的，连续的异步传输很可能将buffer耗光。