kmalloc与vmalloc的区别

     《linux内核情景分析》中，有一段提到kmalloc和vmalloc的区别，说kmalloc申请的页是物理连续的，vmalloc是逻辑地址连续，但是物理页并非连续，因此vmalloc可能带来较大的tlb抖动，效率较低。

      前面就思考过这个问题（当时还没有自己研究过linux内存管理），当时曾经这么理解的：新的x86 cpu是可以支持4M的大页表，物理上连续的小页可以合并为大页，这样申请同样大小的内存，kmalloc所需要的页表条数会比vmalloc少。既然页表条数少了，自然tlb的抖动会减少。

      仔细研究过《understand linux virtual memory manager》之后，发现原来的想法有些naive，一厢情愿的味道，误解了作者的意思。其实vmalloc申请的物理页一般是从high_mem zone申请，申请之后需要为这些物理页创建单独的页表，从而引起tlb的flush。而kmalloc申请的物理页是从normal_mem的zone申请，normal_mem zone的物理页，在内核页表映射初始化的时候就已经建好了，即所谓的直接内存映射。

 

    更重要的问题还有一个内核页表共享的问题。kmalloc申请的内存，在第一个进程初始化时就把页表构造好了，这样所有fork出来的进程，其自己的页表都是具有这些页表项。但是vmalloc申请的内存的页表，只是写入了主内核页表。后面的进程再来读写这段虚拟地址空间时，可能需要到page_fault的中断处理程序中去把相应的页表更新。

   仔细研究了下2.6早期版本的代码（2.6.5-7.308-smp），对于后面访问vmalloc区域的进程，是否会导致page_fault的问题，比想象中复杂。每个fork出来的进程，顶级目录都是自己申请的内存。但是顶级目录（pgd）的内核部分的条目，初始化的赋值是从主内核页表的对应位置拷贝过来的。这就导致了两种情况：

     1. 对于采用了pas 3级页表的32位x86架构来说，其顶级目录就4条目，只有最后一条记录是给内核空间用的。也就是说进程fork是从主内核页表拷贝过来的pgd的值肯定不为空，所有进程共享内核地址空间的pmd和pte。进程1先于进程2fork，进程2 vmalloc一段内核地址，修改了主内核页表pmd和tpe，同时也就相当于修改了进程1的内核页表的pmd和pte。进程1内存中的pagetable来说，这段vmalloc新申请的虚拟地址的页表映射是完全的，进程1去访问它的时候是否会产生page fault呢？这个问题比较复杂。如果进程进程2 vmalloc的时候进程1不占有处理器，那么当进程1占有处理器后，不清楚mmu是否会从内存中重新导入内核页表项（因为内核页表项可以声明为全局的），这个完全依赖于x86 的arch。如果进程1占有cpu，这就要看tlb未命中时，mmu可能会去内存更新tlb然后再看是否要做page fault。

      2.对于采用的2级页表的32位x86，由于pgd有1k条记录，进程1 fork时，拷贝主内核页表中vmalloc区域的pgd条目很可能是个空值（在vmalloc调用前），那么进程 2 vmalloc后，进程1再去访问时，自己的pgd可能都是无效的，因此很可能会page fault去同步pgd。但是很奇怪的地方是，page fault的中断处理程序中，同步的是pmd，而不是pdg。当然对于2级页表，同步这两个都是一样的。

     对于2.6.32的后期版本内核，代码比较复杂，特别有很多半虚拟化xen的东西，进程1在fork时，对于主内页表的拷贝有多种策略，进程内核空间的pmd可能是共享的，也可能是独立的，因此page fault的时候需要同步pmd。

     这里又想到了所谓的numa问题。主内核页表是否在每个memory节点上都有拷贝？如果只有一个拷贝，共享pmd会导致其他cpu（不在主内核页表的节点上的）在更新tlb时会做跨节点访问。如果多个拷贝，总的内存占用多了，但是cpu访问内存的locality比较好，当然，多个拷贝之间同步问题，更复杂。

     一个内核页表的共享问题也是这么复杂啊，OS考虑东西太多了，需要trade off。