工作于内存和文件之间的页缓存.docx

age Cache, the Affair Between Memory and Files工作于内存和文件之间的页缓存?Previously we looked at how the kernel?manages virtual memory?for a user process, but files and I/O were left out. This post covers the important and often misunderstood relationship between files and memory and its consequences for performance.作者之前的一系列文章展示了内核是如果管理一个用户进程的虚拟内存，但是没有涉及到文件和I/O。这篇文章将描述一些重要的并且常常被误解的文件与内存之间的关系，以及由此而来的效率问题。?Two serious problems must be solved by the OS when it comes to files. The first one is the mind-blowing slowness of hard drives, and?disk seeks in particular, relative to memory. The second is the need to load file contents in physical memory once andshare?the contents among programs. If you useProcess Explorer?to poke at Windows processes, you’ll see there are ~15MB worth of common DLLs loaded in every process. My Windows box right now is running 100 processes, so without sharing I’d be using up to ~1.5 GB of physical RAMjust for common DLLs. No good. Likewise, nearly all Linux programs need ld.so and libc, plus other common libraries.当处理文件时，有两个关键的问题需要操作系统来解决。一是磁盘的速度相对与内存来说很慢，特别是磁盘的寻道时间很慢。二是需要把文件内容加载到物理内存并且需要在一些程序之间共享这些信息。如果你使用Process Explorer来查看windows进程，你就会发现每个进程都会加载了一个大约15MB的共同DLL。作者的windows上有100个进程，如果没有共享机制，光是这些共同的DLL就会占据大约1.5GB的物理内存，这是不可能的。同样，在所有的linux程序中，都会需要ld.so和libc这两个共享库，当然还会有一些其它常用的库。?Happily, both problems can be dealt with in one shot: the?page cache, where the kernel stores sized chunks of files. To illustrate the page cache, I’ll conjure a Linux program named?render, which opens file?scene.dat?and reads it 512 bytes at a time, storing the file contents into a heap-allocated block. The first read goes like this:值得高兴的是，以上两个问题都可以通过一个件事情来缓解：这就是页cache，它被内核用来存储页大小的一系列文件内容。为了描述页cache，我构造了一个叫做render的Linux程序，它会打开scene.dat文件并且一次读取它的512字节数据，把这个文件的内容保存在堆上分配出来的block中。第一次的读操作如下图所示：1. render会向内核发出从scene.dat读取开头的512字节的请求2. 内核首先在它当前的页cache中查找是否有4KB大小的一个项是包含scene.dat的满足要求的页cache项。这里假设页cache中还没有相应的数据3. 内核就会分配页frame，然后发起读取scene.dat的前4KB的数据并初始化刚分配出来的那个页frame。4. 内核从这个页frame中把开始的512个字