linux 内存布局以及tlb更新的一些理解
x86架构，问题：
1.内核线程是否有vma线性区？
2.单线程的一个进程，它修改了自己的页表，是否需要发送ipi来通知其他核更新tlb？
3.普通进程，在32位和64位，对应的线性区的最大地址能到多少？
在64位中，linux内核默认的内存布局是：
ffffffff ffffffff _____________
| |
| 内核空间 |
ffff8000 00000000 |____________|
| |
| 未使用 |
| 的空间 |
| |
00007fff ffffffff |____________|
| |
| 用户空间 |
00000000 00000000 |____________|
也就是用户空间占用的位数是47位，内核空间也是47位，所以整体可以寻址的是2的48次方，也就是256T，足够用了。
那另外0xffff,8800,0000,0000 – 0xffff,c7ff,ffff,ffff这64T直接和物理内存进行映射，0xffff,c900,0000,0000 – 0xffff,e8ff,ffff,ffff这32T用于vmalloc/ioremap的地址空间。
而32位地址空间时，当物理内存大于896M时（Linux2.4内核是896M，3.x内核是884M，是个经验值），由于地址空间的限制，内核只会将0~896M的地址进行映射，而896M以上的空间用做一些固定映射和vmalloc/ioremap。而64位地址时是将所有物理内存都进行映射。
64位里面没有了那些高端内存的说法，所以内存管理和映射反而简单了。借用csdn中搜索的图（图中有对应水印），用户态地址布局如下：
内核态地址布局如下：
现在看第一个问题：内核线程，借用了别人的mm作为active_mm,它其实没有vma的，vma里面都是关于用户态地址的。由于内核线程不访问用户态地址空间，则不需要vma。（有同事提醒说，如果一个内核线程故意去访问用户态的数据区，这种也需要访问用户态地址空间，但我没见着这么用过的，自己写的内核线程倒是可以这么做）
一个多线程的进程，在内核中，看到的mm_struct(简写为mm，下同）中的计数如下：
crash> mm_struct.mm_users 0xffff8857b5ef92c0 mm_users = { counter = 904 } crash> mm_struct.mm_count 0xffff8857b5ef92c0 mm_count = { counter = 46 }
mm_user是这个进程中的线程个数的体现，也就是这些线程共用这个mm，
如果是内核线程借用mm作为active_mm，则计数增加是在mm_count中，对于只有一个线程的进程而言，如果调度出去，那么它的mm如果被内核线程借用的话，则mm有两个计数，应该分别为：
mm_user =1,而mm_count=2.(其中一个是本身的计数，一个是内核线程引用的计数)。
初始状态下，这两个值都是1。当 mm_users 减为 0 时，mm_count 会自减 1。也即是仅当 mm_users 减为 0 时，mm_count 才可能为 0。
mm_count 代表了对 mm 本身的引用，而 mm_users 代表对 mm 相关资源的引用，分了两个层次。
可能存在这样的情况，mm 已经没有人使用了（mm_users为0），所以其相关资源被释放掉（如vma）；但是 mm 本身可能还在被人借用（比如被一个内核线程，它不会使用vma），所以 mm 本身还不能被释放；这句话不知道怎么写比较好，就像中国人说，夏天能穿多少穿多少，冬天能穿多少穿多少一个道理。
现在来看第二个问题，关于tlb的刷新问题，首先要明白tlb中，有标记为Global（后面简称G）的部分，也有不是的，为G的属于内核，所有进程通用。ipi是实现tlb更新的一种方式，但不是唯一方式。处理器不能自动同步他们自己的tlb，因为决定线性地址与物理地址之间的映射有效性的，是内核，而不是硬件本身。
当这个单线程的进程A调度到其他的cpu上，他的mm可能还被其他内核线程借用着，这个时候如果该线程A修改了自己的页表集，不管是G的条目还是非G的条目，自然要体现在当前cpu的tlb上，如果是G项，则会flush_tlb_all，此时的目的cpu是所有cpu，如果非G项，就会发送ipi通知相关的cpu，发送的目的cpu，就在mm的cpumask_allocation成员中（2.6的代码是在cpu_vm_mask），由于被借用，所以如果借用的内核线程运行的cpu和当前A线程运行的cpu不一致的话，则cpumask_allocation 中就有两个cpu位被置位。此时使用的函数主要有flush_tlb_mm和flush_tlb_range等，针对的是非G的条目。关于cpumask_allocation,可以用如下的crash来验证：
crash> mm_struct.cpumask_allocation 0xffff8852eb41abc0 cpumask_allocation = { bits = {562949953421312, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} } crash> px 562949953421312 $2 = 0x2000000000000 fpu = { last_cpu = 49, has_fpu = 1, state = 0xffff8823f52dc980 },
借用A的mm的内核线程B，因为启用lazytlb模式，虽然收到了ipi请求刷新tlb，非G条目，就不会更新其tlb，并将其cpu从对应的mm->cpu_vm_mask删除。一旦删除，以后都不会再收到非G条目的更新了，因为发送方是根据cpu_vm_mask（3.10是cpumask_allocation）来发送ipi请求的。当该内核线程被切换出去的时候，如果被替换的mm刚好和自己的mm一样，则内核调用__flush_tlb 来使得该cpu的所有非全局tlb表项失效。
第一次看到这个地方，还很迷糊，明明和自己的mm一样，为啥还要刷，后来想了下，由于lazytlb模式，自己当时已经不刷tlb了，也就是虽然mm一样，但和该进程的mm里面的各个vma对应的页表已经不一样了，存在脏的tlb，如果不刷，有可能导致访问异常。就是偷懒了没刷，到头来发现mm一样，还得刷，但这种概率不高，特别是单线程的程序。
如果mm不一样，自然天生要刷。这个就是lazytlb的。
最后来看第三个问题，由于线性区里面对应的地址都是用户态的，所以应该一个是3G，一个是2的47次方了，跟布局有关系。这个和第一个问题有些相关。
ps:lazytlb,在vmalloc中也有体现，就是vfree流程中，对于tlbflush操作，采用lazy模式，此时并不真正free，等收集一部分之后，再free，同时刷tlb，防止每次free都去刷tlb，提高了性能。具体可以查看 free_vmap_area_noflush ，lazy_max_pages 等函数。
