以前在项目中，大家为了避免自己使用的page被换出，使用的方式是mlock，从mlock的实现的看，它限制了page被swap，
然后在一个swap off的系统中，这样其实和mlock调用与否没有关系了。
我们使用mlock，最终的目标无非了latency，但是mlock却没有阻止内核将页面进行迁移，也就是虽然保证了对应的虚拟地址
访问的时候不会需要swap迁入，但无法保证对应的物理页面和虚拟地址对应关系不变，如果变化了，访问该虚拟地址的话，还会
出现pagefault，虽然不会io，但对于实时性要求高的场景，依然不爽。
有人提出，干脆pin住内存吧，也就是不让他swap，也不让他迁移，这样物理页面和虚拟地址的对应关系一直不变，是不是就解决了
这个问题呢？这样就带来了一个问题，既然你可以pin住那么多内存，相当于在mm的地盘划出来了一片自留地，这种虽然比系统上电
的时候reserve部分内存，改动起来方便一些，但就不好管理了，为了更好地追踪这个pin住的页面，就有必要固定页保留在单独的虚拟内存区域（VMA）中，
该区域用 VM_PINNED标志标记（不过我在较新的内核中也没找到这个合入）？
这个pin住的页面和我们 mdev中看到的
.pin_pages = vfio_iommu_type1_pin_pages,
.unpin_pages = vfio_iommu_type1_unpin_pages,
是一样的么？不是的，从实现可以看出，这个pin_pages只是加了引用计数，这个页面的物理地址和虚拟地址映射保持不变，但没有防止它被swap。
总而言之：
vfio_iommu_type1_pin_pages内部是通过try_get_page(page)将struct page的_refcount加一，来实现所谓的「pin住内存」的效果的。这样做的实际效果是：
该物理页仍可以被换出
该页不会被迁移，即虚拟地址和物理地址的对应关系被锁定
另一方面，mlock系统调用的「锁住内存」，其含义则是：
内存不会被换出
内存可以被迁移，即虚拟地址不变，物理地址改变
而mpin的实现，则是两者的交集，即不会换出，也不会改变映射关系，它处于nomoveable区域。具体可以参考《https://lwn.net/Articles/600502/》。
从统计的角度说，目前使用pin_pages方式pin住的内存，统计计数也是放在
mm->locked_vm 中，这个和mlock调用并lock的内存是放在同一个成员，并没有区分。
