Windows 10: Memory compression

这篇文章来自Windows 10 Insider Hub。我们知道在8月19号早晨（以下皆为北京时间）微软向insider会员推送了Windows 10 Build 10525预览版，这是TH2分支的第一个预览版本，带来了一些新特性，其中就包括接下来要翻译的这篇文章中提到的，关于win10的内存压缩技术。

 

以下是全文翻译，感谢Explorare，BinotaLiu以及SimonChan等的协力。

在“内存压缩”这项特性发布之后，我们收到了相当多insider会员要求得到更多详细信息的问询。这篇文章将试图深入介绍内存管理器以及内置的内存压缩引擎的内部机制。

With the announcement of the Memory compression feature, we have received a lot of queries from the insiders asking for more information. This post tries to go in-depth into the inner working of the Memory Manager and the memory compression engine built within it.

任何操作系统的一个主要目标就是高效的管理和共享系统资源。一个操作系统能否恰当的处理内存竞争非常重要，因为它影响着用户对系统响应速度的感觉。

One of the primary goals of any operating system is to manage and share resources efficiently. How well an operating system arbitrates competing memory requirements is particularly important, because it impacts the user’s perception of system responsiveness.

在Windows 10中，我们使内存管理器（Memory Manager, MM）能够压缩不常用的内存分页以减少对磁盘（页面文件）的读写并提升响应速度。通过压缩内存我们大大减少了每进程的内存使用，且允许操作系统在进行传统分页方式前让更多的应用同时运行在物理内存中。

In Windows 10, we enabled the Memory Manager (MM) to compress infrequently-accessed memory pages which reduces the amount of reads and writes to the disk (pagefile) and therefore improves responsiveness. By compressing memory we reduce the amount of memory used per process, allowing the operating system to maintain more applications in physical memory at a time before enacting traditional paging.

一旦内存管理器决定使用页面文件，将写入或者被读取的磁盘页面文件数据量相较于原始大小减少了约60%。这个压缩操作通过降低额外的IO负荷的主要来源（应该指物理内存与页面文件间的数据交换造成的读写操作）来提升系统上其他无关操作的表现。最终带来的是更快速高效的应用加载体验以及持久的速度表现。

When Memory Manager’s policy does dictate paging, the data being written to or read from the disk is already compressed to typically around 40 percent of its original size. This compression improves the performance of other unrelated operations on the system by reducing a major source of interfering IO load. The end result is a snappier, more responsive experience with improved app launch performance and consistency.

在细致解释Windows 10的改变之前，我将描述一些Windows内存管理的基本概念并且概述执行数据压缩之前它（意指MemCompression）是如何运作的。

Before explaining the Windows 10 changes in detail, I’ll describe some of the fundamental concepts in Windows memory management and give an overview of how it was performed prior to implementing compression.

第一个概念：工作集是某个进程正在使用的物理内存。一个私有工作集代表这部分物理内存专属于某一个进程。进程也可以接触那些“可共享（多个进程可以共用的内存分页）”的物理内存页面。当你在任务管理器中观察“进程”页面时，特定进程的内存使用量实际上表示它当前的私有工作集。注意为了简化说法，下面我提到“工作集”时都代表“私有工作集”。

The first concept is a working set which is the actively-used physical memory of a process. A private working set represents physical memory that is unique to a process. Processes also touch other pages of physical memory that are “shared,” which several processes can reference. When you look at the Processes view in Task Manager, the memory for a specific process is actually its current private working set. Note that for simplicity when I refer to a “working set” in this post, I mean a “private working set.”

一个程序工作集分页的某些子集似乎不常被使用，同时因为内存是一种受限的资源，需要被有效使用，那些页面必须被回收以供其它进程利用。当MM认为一个分页长时间不活跃时，它将其放入“已修改”列表（Modified list，这里参考资源监视器的翻译）。一个异步进程向磁盘上的页面文件写入分页，然后在内存中把它们从“已修改”移动到“备用”范围(Standby list）。一旦内存被另一个进程从“备用”列表回收了， 但是原始进程仍想查找这个分页，数据就可以从页面文件中恢复。

Some subset of a process’s working set pages are likely to be used only infrequently, and since memory is a limited resource that needs to be used efficiently, those pages must be reclaimed and made available for use by other processes. When MM decides a page has been inactive for long enough, it puts it on the modified list. An asynchronous process writes pages in the modified list to the pagefile on disk and then - in memory - moves them from the modified list to the standby list. This write happens so that if the memory is reclaimed from the standby list by another process, but the original process comes looking for its page, the data can be retrieved from the pagefile.

然而，“备用”中的内存分页还没有被系统回收，所以直到MM为其他进程的工作集重新分配内存分页前他们可以保留其中的数据。如果所属的应用请求在回收前继续使用它们，那么这些分页将会再次利用。这被称为软中断（soft fault）。但是如果一个分页已经被重新利用，此时原始进程向MM请求那个分页时，会发生硬中断（hard fault）。原始进程现在要请求一个已经被其他进程拿走的内存数据，所以操作系统必须发出一个磁盘读取IO去恢复它。

However, pages on the standby list haven’t yet been reclaimed, so they retain their data until MM repurposes them for another process’s working set. They can be reused by the app that previously owned them if that app asks for the page before it is reclaimed. This is called a soft fault. But if a page has been repurposed, and the original process asks MM for that page, a hard fault occurs. The original process is now asking for memory that has been taken by another process, and the OS must issue disk read IO to retrieve it.

正如前面解释的，当面临内存压力时，MM决定哪些页面应该被移动到“已修改”列表。这被称为“trimming（清理）”。但是Windows 8已经为要进行完整交换（swapped）的通用Windows平台（Universal Windows Platform，UWP）应用增加了这个能力——也就是说在应用级别而不是分页粒度级别交换数据（这句感觉没翻通）。这样做是因为UWP应用在后台会挂起（即在用户切换回来之前应用都不会继续运行）。直到彻底恢复前应用将不会创建任何新分页，所以交换整个应用的内存数据是安全的。磁盘IO会连续读取所交换应用的数据，这样要比随机读取快的多。需要了解更多有关Windows 8 MM对UWP应用内存数据交换的信息，可参见这篇文章（post by Bill Karagounis）。

As explained earlier, MM, when faced with memory pressure, determines which pages should be moved to the modified list. This is called trimming. But Windows 8 added the ability for Universal Windows Platform (UWP) applications to be swapped out in their entirety - i.e. at app rather than at page granularity. This is done because UWP apps are suspended when not in the foreground meaning they won’t be running until the user switches back them. No page will be touched until the app is brought back in its entirety, so it’s safe to swap out the whole application. The disk IO required to swap the application back in is then entirely sequential reads, which are dramatically faster than random reads. For more information about the swapping of UWP apps in Windows 8 MM, see this blog post by Bill Karagounis.

Windows 10在页面文件和分页活动之间引进了一个操作层面来允许把压缩过的分页移入“已修改”列表。这意味着当MM意识到内存压力时，它将对不再使用的分页进行压缩而不是把它们写入磁盘。现在MM只在压缩机制不足以缓解内存压力时执行磁盘IO操作。相比从前，利用该策略大大减少了磁盘操作请求，而更多的数据得以被存储在内存中。这都是压缩机制的功劳。

Windows 10 introduces a layer between the pagefile and normal paging activity which allows for the compression of all pages moved to the modified list. This means that when MM feels memory pressure, it will compress unused pages instead of writing them to disk. MM now only performs disk IO when compression isn’t enough to relieve memory pressure. Using this strategy, fewer disk operations are required since - thanks to compression - more data can be stored in memory than before.

这是通过使用一个在内存中被称为压缩存储（compression store）的一系列压缩了的分页集合概念做的实现。所有的 Windows 桌面应用和非 UWP 应用共享一个储存区，而每个 UWP 应用都有其独立的储存区（以启用清除和交换功能）。MM会把“已修改”列表中的分页压缩后放入合适的物理内存区域而不是直接写入页面文件。

This is achieved by using a concept called a compression store, which is an in-memory collection of compressed pages. There’s a single system store for legacy Windows desktop apps or any other non-UWP app memory usage, and then one store for each Windows Runtime app (in order to enable trimming and swapping accordingly). Instead of writing pages in the modified list to the pagefile, MM compresses them and places them in the appropriate store.

该存储区域存在于系统进程工作集中。注意在上方的示意图里因为格式的原因我们把系统工作集和其他工作集区分开了，但是实际上系统工作集跟其他工作集没什么两样。乍一看可能很奇怪，因为 System 进程在内存中保存着所有的储存区，所以在内存被压缩并对其它程序可用的时候，它本身的工作集也增大了。这些在任务管理器中可见。

The stores live in the system process’s working set. Note that in the diagram above we’ve displayed the System Working Set separately from the other Working Sets for formatting reasons, but the System Working Set is a working set like any other. Though perhaps counterintuitive at first glance, since the system process holds the stores in memory, its working set grows larger exactly when memory is being made available to other processes. This is visible in the task manager.

首先，观察System进程的内存使用量。

First, observe the amount of memory used by the System process:

然后，打开几个app并将他们最小化到任务栏。

Then, start and suspend some applications:

这时System进程的工作集便会开始增大。

And the System process’s working set will grow:

每个存储空间会在必要的时候整理自身碎片来确保良好的压缩率。在实践中，压缩过的内存减小了60%的大小，而在一台典型设备上进行的测试表明，Windows 10比以往的Windows操作系统减少了一半的磁盘页面文件写入操作。这将降低所有设备的IO等待时间，并可提高基于闪存硬盘的系统的预期寿命。

Each store manages fragmentation by compacting itself when necessary to ensure a good compression ratio. In practice, compressed memory takes up about 40% of the uncompressed size, and as a result on a typical device running a typical workload, Windows 10 writes pages out to disk only 50% as often as previous versions of the OS did. This will reduce the amount of time spent waiting for IO on all devices, but it will also improve the expected lifespan of systems featuring flash-based hard drives.

虽然压缩能让系统在开启同样多的程序时拥有更多的可用内存，但依旧有必要保留磁盘上的分页文件。在Windows 10中，这通过从 System 进程存储区向“已修改”列表移动内存分页实现。如果分页从系统进程移到“已修改”中，MM就会知道它们已压缩过且随时可被写入页面文件。 因为分页数据得到了必要的压缩，所以磁盘写入量得到减少。也就是说MM只会把已压缩并且存储于系统进程中的分页写入磁盘。

Though compression affords the OS more space in memory for a given application load, paging to disk may still be necessary. In Windows 10, this works by moving pages from the stores in the system process to the modified list. If pages come to the modified list from the system process stores, MM knows they’ve already been compressed and are ready to be written to the pagefile. The writes to disk will be smaller since the pages are necessarily compressed, i.e. the only pages MM will write to disk are ones which have been compressed and stashed in a store in the system process.

那么接下来我们开始聊聊进程是如何从压缩存储区或者磁盘上的页面文件中找回数据的。第一种情况下，当进程发现当前已压缩的分页数据有错误时，MM 只需将所需分页解压并放回对应进程的工作集中——这是发生了软中断故障（soft compression fault）。对于后一种情况，MM会先尝试第一种解决方法，然后发现所请求的分页的压缩数据并不在内存中（好萌）。System 进程工作集会将此分页的压缩数据标记为硬中断，MM就从磁盘中取回数据，最后解压缩并把数据添加到相应故障的进程的工作集里。

So now let’s talk about how a process gets its data back either from a compression store or from the pagefile on disk. In the former case where a process faults on a page which is currently in a compressed store, MM simply decompresses the page and puts it back in the requesting process’s working set - a soft compression fault. But in the latter case, MM tries the former and finds that the compressed data for the page is not in memory. The system process working set then hard faults on the compressed data for the page and MM reads it back in from disk. Decompression and adding to the faulting process’s working set follow.

解压缩是一项高度可并行的操作，所以Windows可以在一次移动多重分页时更有效率。正因如此，缓存UWP应用（相对于清理）表现更佳。不仅仅是解压缩，Windows也为设计在缓存过程中的连续读取行为添加了并行处理能力，目的是提升分页写回内存的速度。它每次读取一个块，接着在等待下一次IO操作完成的同时利用多核CPU的并行处理能力解压缩数据。由于磁盘传输速度瓶颈导致使用者感觉反应迟缓的硬件平台，换用Windows 10后响应速度将会提高。

Decompression is a highly parallelizable operation, so Windows can be efficient when moving multiple pages at once. Because of that, swapping UWP applications (as opposed to trimming) performs particularly well. But it’s not just the decompression: Windows combines that parallelizability with the sequential reads designed into the swapping procedure to read pages into memory extremely quickly; it reads a block at a time, and, while waiting for the next IO operation to complete, it’s simultaneously decompressing the data it just read in parallel using multiple CPUs. Where before a platform might have felt sluggish due to the transfer rate of its disk, running Windows 10 the same hardware appears much more responsive.

归根结底，内存压缩功能（Memory compression）允许Windows 10在所有平台通过减少物理内存占用率使可用内存更有效的被利用，最终实现更少的页面文件IO操作以及对磁盘性能的依赖。从长远角度来讲，它提升了MM决定写入页面文件时的磁盘读写速度。总之，我们希望用户在任何运行Windows 10的设备上获得全面提升的响应速度及使用体验。

In summary, Memory compression allows Windows 10 to make better use of available memory on all systems by reducing physical memory utilization, resulting in fewer pagefile IO operations and a reduced reliance on disk. Furthermore, it improves the speed of writing to and reading from disk when MM determines paging must be enacted. In sum, we expect users to experience improved overall responsiveness and usability on all devices running Windows 10.

感谢阅读。

Ethan Creeger，基础平台团队项目经理。已在内核硬件方面（如ACPI，PCIE）为Windows（及微软）工作两年。