深入解析Linux虚拟内存管理机制

5星 · 超过95%的资源需积分: 10 80 浏览量更新于2024-07-29 3 收藏 8.32MB PDF 举报

"深入理解Linux虚拟内存管理.pdf" 深入理解Linux虚拟内存管理是计算机科学领域中的一个关键主题，尤其是在操作系统设计和优化中。Linux虚拟内存管理（VMM）系统是Linux内核的重要组成部分，它负责有效地分配、管理和回收内存资源，以确保系统的高效运行和稳定性。以下是对这个主题的详细阐述： 1. **虚拟内存概念**：虚拟内存系统允许每个进程拥有独立的地址空间，仿佛每个进程都独享全部物理内存，但实际上，物理内存是所有进程共享的。这种机制提高了系统的安全性和隔离性，因为进程无法直接访问其他进程的内存。 2. **页表与地址转换**：Linux VMM通过页表实现虚拟地址到物理地址的映射。每个进程都有自己的页表，用于记录虚拟页与物理页之间的关系。当进程访问虚拟地址时，CPU会自动完成地址转换。 3. **分页与分段**：Linux采用分页机制管理内存，将内存划分为固定大小的页。尽管早期的系统中也有分段机制，但在现代Linux中，分段主要被用于实现共享库和保护内存区域。 4. **内存分配策略**：Linux VMM有多种内存分配策略，包括匿名页面（无文件对应）、交换（swapping）和文件映射。匿名页面主要用于进程堆栈、数据段等，交换则用于将不常使用的内存写入磁盘，释放物理内存，而文件映射则直接映射文件到内存，提高I/O效率。 5. **内存换出与换入**：当物理内存不足时，Linux会将不活跃的页换出到磁盘上的交换分区，以便腾出空间给活跃进程使用。当这些页再次被访问时，会被换回内存。 6. **内存碎片管理**：VMM通过内存整理和伙伴系统防止或减少物理内存碎片。伙伴系统是一种动态内存分配算法，它将内存块分成不同大小的对，并在分配和回收时保持平衡。 7. **内存缓存与缓冲区**：Linux使用缓冲区缓存和页面缓存来优化磁盘I/O。缓冲区缓存用于存储文件系统的元数据，而页面缓存用于存储文件内容，这极大地提升了磁盘数据读取速度。 8. **内存压力与OOM杀手**：当系统内存压力过大，无法分配新的内存时，Linux会触发OOM（Out-Of-Memory）机制，选择并终止一个或多个进程以释放内存。OOM杀手根据进程的优先级和内存使用情况做出决策。 9. **内存访问权限**：Linux VMM通过页表项中的标志位控制对内存的读、写和执行权限，防止非法访问和执行数据作为代码。 10. **内存故障处理**：页缺失（Page Fault）是虚拟内存常见的异常，发生于进程试图访问尚未加载到物理内存的页时。VMM会处理页缺失，将所需页从磁盘加载到内存，或者在交换策略下，将其他页写回磁盘。了解和掌握Linux虚拟内存管理对于系统管理员、软件开发者和性能优化专家至关重要，因为优化内存使用可以显著提升系统性能和响应速度，尤其是在资源有限的环境中，如嵌入式系统和服务器平台。《深入理解Linux虚拟内存管理》这本书提供了详细的技术细节和实践指导，是深入研究该主题的宝贵资源。

xvi Preface

• A live version of CodeViz, the tool used to generate call graphs for the book,

is available. If you feel that the book’s graphs are lacking some detail you

want,generate them yourself.

• The VMRegress, CodeViz and PatchSet packages, which are discussed

in Chapter 1, are available in /cdrom/software. gcc-3.0.4 is also provided

because it is required for building CodeViz.

Mount the CD on /cdrom as follows:

root@joshua:/$ mount /dev/cdrom /cdrom -o exec

The Web server is Apache 1.3.27 (http://www.apache.org/)andhas been built

and conﬁgured to run with its root as /cdrom/.Ifyour distribution normally uses

another directory, you will need to use this one instead. To start it, run the script

/cdrom/start

server.Ifnoerrors occur, the output should look like:

mel@joshua:~$ /cdrom/start_server

Starting CodeViz Server: done

Starting Apache Server: done

The URL to access is http://localhost:10080/

When the server starts successfully, point your browser to http://localhost:10080

to avail of the CD’s Web services. To shut down the server, run the script

/cdrom/stop

server,andtheCDmay then be unmounted.

Typographic Conventions

The conventions used in this document are simple. New concepts that are in-

troduced, as well as URLs, are in italicized font. Binaries and package names

are in bold.Structures, ﬁeld names, compile time deﬁnes and variables are in a

constant-width font. At times, when talking about a ﬁeld in a structure, both the

structure and ﬁeld name will be included as page→list,forexample. File names

are in a constant-width font, but include ﬁles have angle brackets around them like

<linux/mm.h> and may be found in the include/ directory of the kernel source.

Acknowledgments

The compilation of this book was not a trivial task. This book was researched and

developed in the open, and I would be remiss not to mention some of the people

who helped me at various intervals. If there is anyone I missed, I apologize now.

First, I would like to thank John O’Gorman, who tragically passed away while

the material for this book was being researched. His experience and guidance largely

inspired the format and quality of this book.

Second, I would like to thank Mark L. Taub from Prentice Hall PTR for giving

me the opportunity to publish this book. It has been a rewarding experience and

Preface xvii

made trawling through all the code worthwhile. Massive thanks go to my reviewers,

who provided clear and detailed feedback long after I thought I had ﬁnished writing.

Finally, on the publisher’s front, I would like to thank Bruce Perens for allowing me

to publish in the Bruce Perens’ Open Source Series (http://www.perens.com/Books).

With the technical research, a number of people provided invaluable insight.

Abhishek Nayani was a source of encouragement and enthusiasm early in the re-

search. Ingo Oeser kindly provided invaluable assistance early on with a detailed

explanation of how data is copied from userspace to kernel space, and he included

some valuable historical context. He also kindly oﬀered to help me if I felt I ever got

lost in the twisty maze of kernel code. Scott Kaplan made numerous corrections to

anumber of systems from noncontiguous memory allocation to page replacement

policy. Jonathon Corbet provided the most detailed account of the history of kernel

development with the kernel page he writes for Linux Weekly News. Zack Brown,

the chief behind Kernel Traﬃc, is the sole reason I did not drown in kernel-related

mail. IBM, as part of the Equinox Project, provided an xSeries 350, which was in-

valuable for running my own test kernels on machines larger than those I previously

had access to. Late in the game, Jeﬀrey Haran found the few remaining technical

corrections and more of the ever-present grammar errors. Most importantly, I’m

grateful for his enlightenment on some PPC issues. Finally, Patrick Healy was cru-

cial to ensuring that this book was consistent and approachable to people who are

familiar with, but not experts on, Linux or memory management.

Anumber of people helped with smaller technical issues and general inconsisten-

cies where material was not covered in suﬃcient depth. They are Muli Ben-Yehuda,

Parag Sharma, Matthew Dobson, Roger Luethi, Brian Lowe and Scott Crosby. All

of them sent corrections and queries on diﬀerent parts of the document, which

ensured that too much prior knowledge was not assumed.

Carl Spalletta sent a number of queries and corrections to every aspect of the

book in its earlier online form. Steve Greenland sent a large number of grammar

corrections. Philipp Marek went above and beyond being helpful by sending more

than 90 separate corrections and queries on various aspects. Long after I thought

Iwas ﬁnished, Aris Sotiropoulos sent a large number of small corrections and sug-

gestions. The last person, whose name I cannot remember, but is an editor for a

magazine, sent me more than 140 corrections to an early version. You know who

you are. Thanks.

Eleven people sent a few corrections. Though small, they were still missed

by several of myownchecks. They are Marek Januszewski, Amit Shah, Adrian

Stanciu, Andy Isaacson, Jean Francois Martinez, Glen Kaukola, Wolfgang Oertl,

Michael Babcock, Kirk True, Chuck Luciano and David Wilson.

On the development of VMRegress, nine people helped me keep it together.

Danny Faught and Paul Larson both sent me a number of bug reports and helped

ensure that VMRegress worked with a variety of diﬀerent kernels. Cliﬀ White, from

the OSDL labs, ensured that VMRegress would have a wider application than my

owntest box. Dave Olien, also associated with the OSDL labs, was responsible for

updating VMRegress to work with 2.5.64 and later kernels. Albert Cahalan sent

all the information I needed to make VMRegress function against later proc utilities.

Finally, Andrew Morton, Rik van Riel and Scott Kaplan all provided insight on the

CHAPTER

Introduction

Linux is a relatively new operating system that has begun to enjoy a lot of attention

from the business, academic and free software worlds. As the operating system

matures, its feature set, capabilities and performance grow, but so, out of necessity

does its size and complexity. Table 1.1 shows the size of the kernel source code in

bytes and lines of code of the mm/ part of the kernel tree. This size does not include

the machine-dependent code or any of the buﬀer management code and does not

even pretend to be an accurate metric for complexity, but it still serves as a small

indicator.

Version Release Date Total Size Size of mm/ Line Count

1.0 March 13, 1992 5.9MiB 96KiB 3,109

1.2.13 February 8, 1995 11MiB 136KiB 4,531

2.0.39 January 9, 2001 35MiB 204KiB 6,792

2.2.22 September 16, 2002 93MiB 292KiB 9,554

2.4.22 August 25, 2003 181MiB 436KiB 15,724

2.6.0-test4 August 22, 2003 261MiB 604KiB 21,714

Table 1.1. Kernel Size as an Indicator of Complexity

Out of habit, open source developers tell new developers with questions to refer

directly to the source with the “polite” acronym RTFS

,orrefer them to the kernel

newbies mailing list (http://www.kernelnewbies.org). With the Linux VM manager,

this used to be a suitable response because the time required to understand the VM

could be measured in weeks. Moreover, the books available devoted enough time

to the memory management chapters to make the relatively small amount of code

easy to navigate.

The books that describe the operating system such as Understanding the Linux

Kernel [BC00] [BC03] tend to cover the entire kernel rather than one topic with the

notable exception of device drivers [RC01]. These books, particularly Understanding

the Linux Kernel,provideinvaluable insight into kernel internals, but they miss the

details that are speciﬁc to the VM and not of general interest. But the book you are

holding details why ZONE

NORMAL is exactly 896MiB and exactly how per-cpu caches

Read The Flaming Source. It doesn’t really stand for Flaming, but children could be reading.

2 Introduction Chapter 1

are implemented. Other aspects of the VM, such as the boot memory allocator and

the VM ﬁlesystem, which are not of general kernel interest, are also covered in this

book.

Increasingly, to get a comprehensive view on how the kernel functions, one is

required to read through the source code line by line. This book tackles the VM

speciﬁcally so that this investment of time to understand the kernel functions will

be measured in weeks and not months. The details that are missed by the main

part of the book are caught by the code commentary.

In this chapter, there will be an informal introduction to the basics of acquiring

information on an open source project and some methods for managing, browsing

and comprehending the code. If you do not intend to be reading the actual source,

you may skip to Chapter 2.

1.1 Getting Started

One of the largest initial obstacles to understanding code is deciding where to start

and how to easily manage, browse and get an overview of the overall code structure.

If requested on mailing lists, people will provide some suggestions on how to proceed,

but a comprehensive methodology is rarely oﬀered aside from suggestions to keep

reading the source until it makes sense. The following sections introduce some useful

rules of thumb for open source code comprehension and speciﬁc guidelines for how

the rules may be applied to the kernel.

1.1.1 Conﬁguration and Building

With any open source project, the ﬁrst step is to download the source and read

the installation documentation. By convention, the source will have a README or

INSTALL ﬁle at the top level of the source tree [FF02]. In fact, some automated

build tools such as automake require the install ﬁle to exist. These ﬁles contain

instructions for conﬁguring and installing the package or give a reference to where

more information may be found. Linux is no exception because it includes a README

that describes how the kernel may be conﬁgured and built.

The second step is to build the software. In earlier days, the requirement for

many projects was to edit the Makefile by hand, but this is rarely the case now.

Free software usually uses at least autoconf

to automate testing of the build

environment and automake

to simplify the creation of Makefiles, so building is

often as simple as:

mel@joshua: project $ ./configure && make

Some older projects, such as the Linux kernel, use their own conﬁguration tools,

and some large projects such as the Apache Web server have numerous conﬁguration

options, but usually the conﬁgure script is the starting point. In the case of the

http://www.gnu.org/software/autoconf/

http://www.gnu.org/software/automake/

剩余747页未读，继续阅读

duanhongle

粉丝: 0
资源: 2

深入解析Linux虚拟内存管理机制

Linux虚拟内存管理.pdf

深入理解Linux虚拟内存管理.pdf

深入理解Linux虚拟内存管理.rar

深入理解Linux内核第3版.pdf

深入理解Linux虚拟内存管理 英文版 PDF

深入理解Linux虚拟内存管理

深入理解Linux虚拟内存管理技术

Linux操作系统内存管理.pdf

深入理解linux虚拟内存管理(中+英)

Linux 内存管理导读 .pdf

最新资源

深入理解Linux虚拟内存管理英文版 PDF