本文主要探索以mmap接口访问文件时，文件自身大小、mmap映射范围和我们所能访问区间之间的关系。主要通过几个小的实验程序来说明。
本文假定读者了解mmap可以作为文件访问的接口，若没有用过可以在Linux中直接man mmap看相关说明，或者去网上搜索其他资料。简单来说，文件的某一段经过mmap系统调用映射后会返回一个地址，这样我们可以像操纵内存一样操纵磁盘上的数据，因此”open +mmap+memcpy+msync “这套文件操作可以在很多的时候代替”open+read/write+fsync“这套文件操作。
但是相比write进行追加写的操作，被mmap映射的地址是无法做到改变被映射文件大小的，那么我们如果想改变文件大小怎么办？如果我们写的地址大于实际文件大小会出现什么情况？如果我们写的地址大于所映射的地址范围会有什么情况？
近年，一些本为内核处理的任务，分别出现用户态的实现，有的是为了提升开发灵活性(FUSE、userfaultfd)，有的则是为了提高与外设通信的性能(SPDK、DPDK)。本系列文章对我所了解到的用户空间实现的内核机制进行使用介绍或原理分析。第一篇文章介绍用户态的缺页处理 — userfaultfd机制，以后还可能根据我的学习进度介绍userfaultfd的内核实现原理、FUSE的使用和原理、SPDK等内容。文章若有错误，恳请指正。
userfaultfd 机制让在用户控制缺页处理提供可能，进程可以在用户空间为自己的程序定义page fault handler，增加了灵活性，但也可能由于类似FUSE之于内核FS的问题(调用层次加深)而影响性能。
以最基本的用户空间进行匿名页缺页处理为例，(例子代码基本来自userfaultfd的man page[1]，)步骤大致如下：
(翻译自qemu 3.0的文档)
|
1 2 |
qemu-img [standard options] command [command options] |
qemu-img 允许你离线地创建、转换或者修改镜像文件。它可以处理所有QEMU支持的镜像格式。
一个文件的长度和它实际所占用的磁盘空间很可能是不同的，这主要涉及到稀疏文件(sparse file)和文件打洞(hole punching)的概念。这两个特性需要操作系统和文件系统的支持，目前Linux的ext4、XFS等文件系统都支持这两个特性。
了解系数文件最直观的例子是，创建一个文件，然后用lseek定位到较大的偏移量，在这个偏移量实际写一些内容，这时实际占用的磁盘空间很小，但文件的长度却比较大。比如：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
#include <fcntl.h> #include <assert.h> int main() { // 打开两个文件file_normal和file_sparse int fd = open("file_normal", O_RDWR|O_CREAT, 0755); int fd_sparse = open("file_sparse", O_RDWR|O_CREAT, 0755); assert(fd != -1); // 一个从0写入3个字节，一个从1000偏移写入3个字节 lseek(fd, 0, SEEK_SET); lseek(fd_sparse, 100000, SEEK_SET); write(fd, "ABCDEFG", 3); write(fd_sparse, "ABCDEFG", 3); close(fd); close(fd_sparse); return 0; } |
为了统计代码行数(lines of code, LoC)，最简单的思路是用python读取每个所输入的代码文件的行数，然后加起来。
本实现分离了代码文件识别和统计，代码文件由用户给出。
Python实现，用enumerate函数统计可以防止内存占用过大的问题，我们要的只是一个计数，每行读完扔掉即可(pass)。代码如下：
Bloom Filter 和 Cuckoo Filter有类似的用途，很多人将它们称为概率数据结构或者近似成员数据结构(approximate membership data structure)。最近看了一个Bloom Filter和一个Cuckoo Filter的比较好的实现，代码都是用C++实现，代码量也不大，读起来没有什么难度。
本文贴出来的是两个项目的大体构成，不涉及到空间、错误率等的理论分析，希望能给需要的新手一些帮助。
两个项目的网址如下：
Consistency这个词在计算机各领域用的很多，比如分布式系统、体系结构和存储系统等等。本文只探讨存储系统crash consistency。Crash Consistency问题在存储系统中都会存在(数据库、文件系统、dedup系统 …)，即系统遭遇断电、崩溃等情况时，相关联的数据没有全部持久化可能导致的不一致。本文以文件系统为例进行说明，所有内容基于自己对相关资料的理解，如有错误，恳请指正！
下表整理自我的OSTEP笔记[1]，我们假设了一个有data和inode、bitmap两种metadata的简单文件系统，下表给出了一些可能导致不一致的情况，其中N表示断电时没有写完，F表示断电时已经完成：
本文是对《A Primer on Memory Consistency and Cache Coherence》这本书前一半内容的记录和理解，主要涉及memory consistency model。
对于多处理器共享内存系统来说，consistency和coherence都关注的是共享内存(shared memory)及cache的正确性问题，而人们把这个问题拆成两个方面是为了更好地将这个复杂问题分治解决。
一般需要被详细讨论的是多核(或线程)共享内存(shared memory)的consistency模型，因为单核单线程问题相对简单直观。内存consistency模型规定的是：多线程同时进行load/store操作时，怎样的执行顺序是对的，怎样是错的。比较简单直接的consistency模型包括sequential consistency、TSO(total store consitency，x86使用)等。
我们应该怎么分析QEMU代码中某段代码的性能呢？除了比较复杂的trace-event功能（我的博客中翻译过qemu tracing的文档），其实在QEMU自带有一个简单的profiler实现，它是一个简单的计时器封装。这篇博客主要介绍怎么在编译时开启、使用QEMU profiler，并说明怎么利用这个功能添加一个自己的计时器来分析QEMU中某段代码的性能。
我的代码是QEMU 2.12.0。要开启profiler功能，在编译前进行运行configure的时候，只要加入--enable-profiler选项就可以了，它会加入CONFIG_PROFILER这个宏定义。比如我用如下选项进行编译：
|
1 2 3 4 5 |
cd QEMU_SRC_PATH ./configure --prefix=/PATH/TO/QEMU_BIN_DIR --target-list=x86_64-softmmu --enable-profiler make -j make install |
日记式的个人胡扯，没有一句话保证正确，谢谢围观，欢迎指正。。
首先举两个极端的例子：深度学习应用十分重要，因此人们愿意专门为它花钱设计新型专用芯片和硬件架构，甚至可能为了它的性能，没准以后会重新写了一个叫”DnnOS”（我自己瞎编的名字）操作系统；而Jc写的helloworld.py程序无论在Linux, Windows 95还是Win 10上怎么折腾，都是打印一行hello, world，没有任何区别的。
哪个更好的问题没有绝对的答案，也许深度学习的新型硬件没有键盘鼠标和显示器，DnnOS也只要实现一套新型硬件的驱动，复杂程度远远小于Linux和Windows。但是Jc的helloworld.py无论运行在多么复杂的系统上，都无法到一个好的深度学习模型所带来的价值；反过来说，即使这套新型深度学习工具再牛逼，可能都无法运行Jc的helloworld.py程序。