linux内存相关

Linux的基本原则是没有资源应该被浪费。因此核心会使用尽可能多的RAM，来缓存来自本地和远程的文件系统的信息。系统做读写操作的时候，会将与当前运行的进程相关的数据尽量存储在RAM里。系统报告的缓存是缓冲和页缓存两者之和。缓存并不是在进程结束的时候被回收（你可能很快会启动另外一个进程，需要同样的数据），而是随需回收--比如，当你启动一个需要大量内存的进程时，Linux核心会从内存中回收缓存，将得到的内存分配给新的进程。

 

有些区域，比如匿名内存映射(mmps)和共享内存区域，它们被报告为缓存，但不是被核心直接释放。一般的缓存不映射到进程的地址空间，仅仅是简单的核心映射，而这些特别的缓存映射到所有挂接到它们上面的进程。

 

下面是一个例子（单位是MB):

 

# free -m

total used free shared buffers cached

Mem: 1000 900 100 0 350 350

-/+ buffers/cache: 200 800

 

在这里例子中，应用程序只使用了200MB内存，还有800MB空闲内存可以使用。

 

一些简单的计算方法：

 

物理已用内存 = 实际已用内存 - 缓冲 - 缓存

物理空闲内存 = 总物理内存 - 实际已用内存 + 缓冲 + 缓存

应用程序可用空闲内存 = 总物理内存 - 实际已用内存

应用程序已用内存 = 实际已用内存 - 缓冲 - 缓存

为什么必须管理内存

 

内存管理是计算机编程最为基本的领域之一。在很多脚本语言中，您不必担心内存是如何管理的，这并不能使得内存管理的重要性有一点点降低。对实际编程来说，理解您的内存管理器的能力与局限性至关重要。在大部分系统语言中，比如 C 和 C++，您必须进行内存管理。本文将介绍手工的、半手工的以及自动的内存管理实践的基本概念。

 

追溯到在 Apple II 上进行汇编语言编程的时代，那时内存管理还不是个大问题。您实际上在运行整个系统。系统有多少内存，您就有多少内存。您甚至不必费心思去弄明白它有多少内存，因为每一台机器的内存数量都相同。所以，如果内存需要非常固定，那么您只需要选择一个内存范围并使用它即可。

 

不过，即使是在这样一个简单的计算机中，您也会有问题，尤其是当您不知道程序的每个部分将需要多少内存时。如果您的空间有限，而内存需求是变化的，那么您需要一些方法来满足这些需求：

确定您是否有足够的内存来处理数据。

 

从可用的内存中获取一部分内存。

 

向可用内存池（pool）中返回部分内存，以使其可以由程序的其他部分或者其他程序使用。

实现这些需求的程序库称为 分配程序（allocators），因为它们负责分配和回收内存。程序的动态性越强，内存管理就越重要，您的内存分配程序的选择也就更重要。让我们来了解可用于内存管理的不同方法，它们的好处与不足，以及它们最适用的情形。

 

C风格的内存分配程序

 

C编程语言提供了两个函数来满足我们的三个需求：

 

malloc：该函数分配给定的字节数，并返回一个指向它们的指针。如果没有足够的可用内存，那么它返回一个空指针。

 

free：该函数获得指向由 malloc 分配的内存片段的指针，并将其释放，以便以后的程序或操作系统使用（实际上，一些 malloc 实现只能将内存归还给程序，而无法将内存归还给操作系统）。

 

物理内存和虚拟内存

 

要理解内存在程序中是如何分配的，首先需要理解如何将内存从操作系统分配给程序。计算机上的每一个进程都认为自己可以访问所有的物理内存。显然，由于同时在运行多个程序，所以每个进程不可能拥有全部内存。实际上，这些进程使用的是 虚拟内存。

 

只是作为一个例子，让我们假定您的程序正在访问地址为 629 的内存。不过，虚拟内存系统不需要将其存储在位置为 629 的 RAM 中。实际上，它甚至可以不在 RAM 中 —— 如果物理 RAM 已经满了，它甚至可能已经被转移到硬盘上！由于这类地址不必反映内存所在的物理位置，所以它们被称为虚拟内存。操作系统维持着一个虚拟地址到物理地址的转换的表，以便计算机硬件可以正确地响应地址请求。并且，如果地址在硬盘上而不是在 RAM 中，那么操作系统将暂时停止您的进程，将其他内存转存到硬盘中，从硬盘上加载被请求的内存，然后再重新启动您的进程。这样，每个进程都获得了自己可以使用的地址空间，可以访问比您物理上安装的内存更多的内存。

 

在 32-位 x86 系统上，每一个进程可以访问 4 GB 内存。现在，大部分人的系统上并没有 4 GB 内存，即使您将 swap 也算上， 每个进程所使用的内存也肯定少于 4 GB。因此，当加载一个进程时，它会得到一个取决于某个称为 系统中断点（system break）的特定地址的初始内存分配。该地址之后是未被映射的内存 —— 用于在 RAM 或者硬盘中没有分配相应物理位置的内存。因此，如果一个进程运行超出了它初始分配的内存，那么它必须请求操作系统“映射进来（map in）”更多的内存。（映射是一个表示一一对应关系的数学术语 —— 当内存的虚拟地址有一个对应的物理地址来存储内存内容时，该内存将被映射。）

 

基于 UNIX 的系统有两个可映射到附加内存中的基本系统调用：

 

brk： brk() 是一个非常简单的系统调用。还记得系统中断点吗？该位置是进程映射的内存边界。

 

brk() 只是简单地将这个位置向前或者向后移动，就可以向进程添加内存或者从进程取走内存。

 

mmap： mmap()，或者说是“内存映像”，类似于 brk()，但是更为灵活。首先，它可以映射任何位置的内存，而不单单只局限于进程。其次，它不仅可以将虚拟地址映射到物理的 RAM 或者 swap，它还可以将它们映射到文件和文件位置，这样，读写内存将对文件中的数据进行读写。不过，在这里，我们只关心 mmap 向进程添加被映射的内存的能力。 munmap() 所做的事情与 mmap() 相反。

 

如您所见， brk() 或者 mmap() 都可以用来向我们的进程添加额外的虚拟内存。在我们的例子中将使用 brk()，因为它更简单，更通用。

 

实现一个简单的分配程序

 

如果您曾经编写过很多 C 程序，那么您可能曾多次使用过 malloc() 和 free()。不过，您可能没有用一些时间去思考它们在您的操作系统中是如何实现的。本节将向您展示 malloc 和 free 的一个最简化实现的代码，来帮助说明管理内存时都涉及到了哪些事情。

 

要试着运行这些示例，需要先 复制本代码清单，并将其粘贴到一个名为 malloc.c 的文件中。接下来，我将一次一个部分地对该清单进行解释。

 

在大部分操作系统中，内存分配由以下两个简单的函数来处理：

 

void *malloc(long numbytes)：该函数负责分配 numbytes 大小的内存，并返回指向第一个字节的指针。

 

void free(void *firstbyte)：如果给定一个由先前的 malloc 返回的指针，那么该函数会将分配的空间归还给进程的“空闲空间”。

 

malloc_init 将是初始化内存分配程序的函数。它要完成以下三件事：将分配程序标识为已经初始化，找到系统中最后一个有效内存地址，然后建立起指向我们管理的内存的指针。这三个变量都是全局变量：

 

清单 1. 我们的简单分配程序的全局变量

 

 

int has_initialized = 0;
void *managed_memory_start;
void *last_valid_address;

 

如前所述，被映射的内存的边界（最后一个有效地址）常被称为系统中断点或者 当前中断点。在很多 UNIX® 系统中，为了指出当前系统中断点，必须使用 sbrk(0) 函数。 sbrk 根据参数中给出的字节数移动当前系统中断点，然后返回新的系统中断点。使用参数 0 只是返回当前中断点。这里是我们的 malloc 初始化代码，它将找到当前中断点并初始化我们的变量：

 

清单 2. 分配程序初始化函数

 

 

/* Include the sbrk function */
#include <unistd.h>
void malloc_init()
{
 /* grab the last valid address from the OS */
 last_valid_address = sbrk(0);
 /* we don't have any memory to manage yet, so
  *just set the beginning to be last_valid_address
  */
 managed_memory_start = last_valid_address;
 /* Okay, we're initialized and ready to go */
  has_initialized = 1;
}

 

现在，为了完全地管理内存，我们需要能够追踪要分配和回收哪些内存。在对内存块进行了 free 调用之后，我们需要做的是诸如将它们标记为未被使用的等事情，并且，在调用 malloc 时，我们要能够定位未被使用的内存。

三、

输出解释

CPU 以及CPU0。。。的每行的每个参数意思（以第一行为例）为：

参数 解释 /proc//status

Size (total pages) 任务虚拟地址空间的大小 VmSize/4

Resident(pages) 应用程序正在使用的物理内存的大小 VmRSS/4

Shared(pages) 共享页数 0

Trs(pages) 程序所拥有的可执行虚拟内存的大小 VmExe/4

Lrs(pages) 被映像到任务的虚拟内存空间的库的大小 VmLib/4

Drs(pages) 程序数据段和用户态的栈的大小 （VmData+ VmStk ）4

dt(pages) 脏页数量

 

通过内核代码，我们可以更加清楚的了解其含义：

 

显示该信息主要是通过 proc_pid_statm 该函数来实现的。如果对proc的机制不了解，请参考《linux设备驱动程序》。

 

其调用过程：proc_pid_statm－>statm_pmd_range->statm_pte_range。目的是从地址区间逐渐转化成具体的每个页表。阅读代码，只需了解一个大概，不用了解很多细节，要比写起来轻松许多。

 

其中totals，pages，shared，dirty的是通过虚拟地址的页表来进行判断。

 

 

do {
    pte_t page = *pte;
    struct page *ptpage;

    address += PAGE_SIZE;
    pte++;
    if (pte_none(page))
       continue;
    ++*total;             //是合法的页都计算在内。
    if (!pte_present(page))
 continue;
    ptpage = pte_page(page);
    if ((!VALID_PAGE(ptpage)) || PageReserved(ptpage))
        continue;
    ++*pages;            //只有页表中含有present标记的，计算在内。
    if (pte_dirty(page))
        ++*dirty;        //页表中dirty标记，计算在内。
    if (page_count(pte_page(page)) > 1)
        ++*shared;       //页表的所有者超过1的，就认为共享。
} while (address < end);

trs、drs、lrs是通过线性地址区间来进行区分的。

int proc_pid_statm(struct task_struct *task, char * buffer)
。。。。。
while (vma) {
。。。。。。。。。。。
    if (vma->vm_flags & VM_EXECUTABLE)      //该线性区间的flags标志为可执行。
       trs += pages; /* text */
    else if (vma->vm_flags & VM_GROWSDOWN)  //该线性区间的flags标志为向下增长。
       drs += pages; /* stack */
    else if (vma->vm_end > 0x60000000)      //结尾线性地址大于0x60000000。
       lrs += pages; /* library */
    else        //这块区间应该是数据区与堆。
       drs += pages;
     vma = vma->vm_next;
}

pages=trs+drs+lrs

 

因此说，trs drs lrs 与totals，pages，shared，dirty两组，分别从两个角度观察内存。

四、

Linux操作系统内存磁盘初始化技术详细解析

Linux内存初始化技术（initrd）用于支持两阶段的系统引导过程，是在系统启动过程中被挂载的临时root文件系统（译者注：这里的root 文件系统是指的根文件系统）。initrd包含很多可执行程序和驱动，并允许在临时的内存磁盘根文件系统被卸载，内存被释放后挂载真实的root文件系统。在许多嵌入式linux文件系统中，initrd是最终的根文件系统。这篇文章主要讲解了linux2.6内核的initrd技术，包括在内核中的创建及使用。

 

什么是内存磁盘初始化？

 

Initrd挂载优先级高于真实根文件系统，它被邦定在内核上，做为内核启动过程的一部分被加载（load）。然后，做为两阶段引导过程的第一部分，内核挂载（mount）initrd，用于获得并加载真实有效的文件系统。

 

为了达到这个目的，initrd包含有最起码的目录与程序，例如insmod，来安装内核模块到内核中。对于桌面或服务器linux，initrd 是临时文件系统，它的生存周期很短，仅仅是做为到达真实根文件系统的桥梁。但对于没有存储设备的嵌入式系统来说，它才是永久性的根文件系统。本篇文章对这两方面均有涉及。

 

深入分析initrd

 

Initrd 包含有必须的程序和系统文件，用于支持系统的启动的第二阶段过程。创建初始化内存的方法，是随着你所使用的系统版本而改变的。从Fedora Core3以后，initrd就由回送设备（loop device）建立。什么是回送设备？它是一个设备驱动，允许你将一个文件挂载为块设备，并对其文件系统做出描述。也许loop device并不存在与你的内核中，但是你能够通过内核的配置工具（make menuconfig）打开它。路径是：

Device Drivers-》Block Devices-》LoopBack Device support。

 

下面为检查命令：

# mkdir temp ; cd temp

# cp /boot/initrd.img.gz .

# gunzip initrd.img.gz

# mount -t ext -o loop initrd.img /mnt/initrd

# ls -la /mnt/initrd

#

现在，你可以通过查看/mnt/initrd的子目录来查看initrd的内容。需要注意的是，即使你的initrd镜像文件并不是以.gz做为后缀名，但是你同样可以通过增加此后缀名来让gunzip打开它。

 

从Fedora Core3开始，默认的initrd镜像就是一个压缩的gpio归档文件。除了用挂载文件的方式以外，你同样可以通过cpio归档的方式来将其挂载成使用了回送设备的压缩镜像。你可以通过以下的指令来检查这个cpio归档文件的内容：

# mkdir temp ; cd temp

# cp /boot/initrd-2.6.14.2.img initrd-2.6.14.2.img.gz

# gunzip initrd-2.6.14.2.img.gz

# cpio -i –make-directories < initrd-2.6.14.2.img

 

你看到的结果将是一个小型根文件系统，如下所示：

 

# ls -la

#

drwxr-xr-x 10 root root 4096 May 7 02:48 .

drwxr-x— 15 root root 4096 May 7 00:54 ..

drwxr-xr-x 2 root root 4096 May 7 02:48 bin

drwxr-xr-x 2 root root 4096 May 7 02:48 dev

drwxr-xr-x 4 root root 4096 May 7 02:48 etc

-rwxr-xr-x 1 root root 812 May 7 02:48 init

-rw-r–r– 1 root root 1723392 May 7 02:45 initrd-2.6.14.2.img

drwxr-xr-x 2 root root 4096 May 7 02:48 lib

drwxr-xr-x 2 root root 4096 May 7 02:48 loopfs

drwxr-xr-x 2 root root 4096 May 7 02:48 proc

lrwxrwxrwx 1 root root 3 May 7 02:48 sbin -> bin

drwxr-xr-x 2 root root 4096 May 7 02:48 sys

drwxr-xr-x 2 root root 4096 May 7 02:48 sysroot

#

 

一些小的，但是很有必要的程序组合能在./bin目录下得到，包括nash（它不是一个shell，而是一个脚本解释工具），用于加载内核模块的insmod，以及lvm等。

 

上面所示目录中，相对比较有趣的是root目录下的初始化文件。这些文件，和传统的linux启动过程中一样，是在initrd镜像被解压缩到RAM中时生成的。待会我们将继续探讨这个问题。

 

创建initrd的工具

 

现在，让我们回到一开始的讨论：initrd的镜像是如何被创建的？在传统的linux系统中，initrd是在linux build的时候被创建的。像mkinitrd这样的许许多多的工具，都能够用于通过必须的库和模块来自动构建一个用于过渡到真实根文件系统的 initrd。事实上，mkinitrd工具是一个脚本文件，因此，我们能够很清楚得看到，这个过程是如何进行的。同样的，YAIRD (Yet Another Mkinitrd)工具，也允许我们自定制每一个initrd被构建的阶段。

 

自己动手，打造自定义的初始化内存盘

 

由于很多基于linux的嵌入式系统都没有硬盘驱动器，initrd也可以做为永久性的根文件系统。下面我就将告诉你们，如何创建一个initrd 镜像。我使用的是标准linux桌面系统，因此大家即使没有嵌入式目标设备也可以照着做。除了交叉编译以外，嵌入式目标文件的构建过程是相同的。

 

#!/bin/bash

 

# Housekeeping…

rm -f /tmp/ramdisk.img

rm -f /tmp/ramdisk.img.gz

 

# Ramdisk Constants

RDSIZE=4000

BLKSIZE=1024

 

# Create an empty ramdisk image

dd if=/dev/zero of=/tmp/ramdisk.img bs=$BLKSIZE count=$RDSIZE

 

# Make it an ext2 mountable file system

/sbin/mke2fs -F -m 0 -b $BLKSIZE /tmp/ramdisk.img $RDSIZE

 

# Mount it so that we can populate

mount /tmp/ramdisk.img /mnt/initrd -t ext2 -o loop=/dev/loop0

 

# Populate the filesystem (subdirectories)

mkdir /mnt/initrd/bin

mkdir /mnt/initrd/sys

mkdir /mnt/initrd/dev

mkdir /mnt/initrd/proc

 

# Grab busybox and create the symbolic links

pushd /mnt/initrd/bin

cp /usr/local/src/busybox-1.1.1/busybox .

ln -s busybox ash

ln -s busybox mount

ln -s busybox echo

ln -s busybox ls

ln -s busybox cat

ln -s busybox ps

ln -s busybox dmesg

ln -s busybox sysctl

popd

 

# Grab the necessary dev files

cp -a /dev/console /mnt/initrd/dev

cp -a /dev/ramdisk /mnt/initrd/dev

cp -a /dev/ram0 /mnt/initrd/dev

cp -a /dev/null /mnt/initrd/dev

cp -a /dev/tty1 /mnt/initrd/dev

cp -a /dev/tty2 /mnt/initrd/dev

 

# Equate sbin with bin

pushd /mnt/initrd

ln -s bin sbin

popd

 

# Create the init file

cat >> /mnt/initrd/linuxrc << EOF

#!/bin/ash

echo

echo “Simple initrd is active”

echo

mount -t proc /proc /proc

mount -t sysfs none /sys

/bin/ash –login

EOF

 

chmod +x /mnt/initrd/linuxrc

 

# Finish up…

umount /mnt/initrd

gzip -9 /tmp/ramdisk.img

cp /tmp/ramdisk.img.gz /boot/ramdisk.img.gz

 

想创建initrd的话，你需要首先创建一个空文件，将/dev/zero（0字符流）做为ramdisk.img的输入。得到的文件大小大约是 4MB（有 4000个1K的块组成）。接下来，用mke2fs命令来创建一个使用这个空文件的ext2文件系统。现在，这个文件就是一个ext2文件系统。ok，接下来，以回路设备的形式挂载这个文件到/mnt/initrd，现在，你就在挂载点拥有一个代表着ext2文件系统的目录，并用与存放你的initrd。其他大多数的脚本语句都是用于实现这个功能。

 

下一步，就是创建一些必须的子目录，用于生成你的根文件系统： /bin, /sys, /dev, 和 /pro。这里只需要少数几个目录，例如，没有/lib。但是它们已经包含了大部分功能。

 

如果想让你的根文件系统发挥更大的作用，请使用 BusyBox。这个工具是一个包含了许多独立工具的镜像，这些独立的工具你都能在linux中找到（ ash, a等等wk, sed, insmod）。BusyBox的优势在于，它把它们集合在了一起，并分享了公用的部分，从而极大缩小了镜像的体积。这对于嵌入式系统来讲，是非常理想的。请将BustBox镜像从它的源目录中复制出来，到你的/bin目录下，这样，很多指向BusyBox工具集的符号链接将被创建，BusyBox能确定哪一个工具将被使用，并自动引用它。这个/bin目录下被创建的链接的小型集合将用于对启动脚本的支持。

再下一步，就是一小部分特殊设备文件的创建。我从我的/dev文件夹中直接拷贝了出来，别忘了加上-a选项来保持它们原有的属性。

 

倒数第二步，就是生成linuxrc文件。在内核挂载了内存盘之后，它将搜索并执行相关的启动文件，如果没有找到，内核就将linuxrc文件做为其启动脚本。你最好在这个文件中对环境变量做一些基本设置，例如挂载/proc文件系统等。除了/proc外，我还挂载了/sys文件系统，将消息发送给终端。最后，我调用ash并通过它和根文件系统交互。最后记住，用chmod把linuxrc文件的属性改为可执行。

 

最后，你的根文件系统算是ok了。现在它并没有被挂载，用gzip将它压缩，并将压缩后的文件ramdisk.img.gz拷贝到/boot目录下，这样它就能被GRUB调用。

 

想要构建你的初始化ram盘的话，你只需要调用mkird，镜像就将自动创建并拷贝到/boot目录下。

 

测试自定义的初始化RAM盘

 

你拥有的新的initrd镜像是在/boot目录下，因此，下一步就是要用你默认的内核来测试它。ok，现在你可以先重新启动你的linux系统，当 GRUB引导画面出现时，按下C键，打开GRUB的命令行工具。现在，你就能通过GRUB确定启动专门的内核和initrd镜像。内核命令是允许你定制内核文件的，而initrd命令则允许你指定专门的initrd镜像文件。当它们都被指定之后，通过启动命令来启动内核，如下所示：

 

GNU GRUB version 0.95 (638K lower / 97216K upper memory)

 

[ Minimal BASH-like line editing is supported. For the first word, TAB

lists possible command completions. Anywhere else TAB lists the possible

completions of a device/filename. ESC at any time exits.]

 

grub> kernel /bzImage-2.6.1

[Linux-bzImage, setup=0×1400, size=0×29672e]

 

grub> initrd /ramdisk.img.gz

[Linux-initrd @ 0×5f2a000, 0xb5108 bytes]

 

grub> boot

 

Uncompressing Linux… OK, booting the kernel.

 

在内核启动之后，它开始检查initrd镜像是否可用，如果答案是确定的，那么就作为根文件系统加载并挂载它。下面就是这个特殊启动过程的结尾：

 

…

md: Autodetecting RAID arrays

md: autorun

md: … autorun DONE.

RAMDISK: Compressed image found at block 0

VFS: Mounted root (ext2 file system).

Freeing unused kernel memory: 208k freed

/ $ ls

bin etc linuxrc proc sys

dev lib lost+found sbin

/ $ cat /proc/1/cmdline

/bin/ash/linuxrc

/ $ cd bin

/bin $ ls

ash cat echo mount sysctl

busybox dmesg ls ps

/bin $ touch zfile

/bin $ ls

ash cat echo mount sysctl

busybox dmesg ls ps zfile

 

当启动之后，可以通过ash来进入命令模式。在本例中，我探究了根文件系统并向你演示了，你能通过新建文件来写入这个文件系统。只需要注意，第一步是要创建linuxrc。

 

通过初始化内存盘启动

 

现在，大家已经看到了如何构建并使用一个自定制的初始化内存盘，这一节则用于介绍，内核是如何辨认initrd并将其作为它的根文件系统挂载的。我将涉及一些boot chain中的主要的函数并对发生的事件做出解释。

 

像GRUB这样的boot loader，通常会确认即将加载的内核并复制该内核镜像与任何相关联的initrd到内存中，你可以在你linux内核源程序目录下的./init子目录中找到这些功能实现。

 

在内核与initrd镜像被解压缩和复制到内存后，内核被调用。此时，开始各种各样的初始化过程，最终，你会发现自己处于init/main.c: init () (subdir/file:function)。这个函数实现了很多的子系统初始化。在这里，要调用init/do_mounts.c: prepare_namespace()，用来准备命名空间(挂载dev 文件系统, RAID, 或者md, devices, 以及, 最后的initrd)。通过对 init/do_mounts_initrd.c:initrd_load()的调用，最终完成对initrd的加载。

 

initrd_load ()调用init/do_mounts_rd.c:rd_load_image()，来决定是否通过调用init/do_mounts_rd.c: identify_ramdisk_image()来加载内存盘镜像。后面这个函数通过检查内核的编号来确定文件究竟是是minux，etc2， romfs，cramfs，还是gzip格式，直到返回initrd_load_image后，init/do_mounts_rd:crd_load ()又被调用。这个函数负责分配空间给内存盘，并进行校验计算，解压缩，最后将内存盘镜像加载到内存中。此时，你就已经拥有了一个适合于挂载的，在块设备中的initrd镜像。

 

现在，通过调用init/do_mounts.c:mount_root()将这个块设备做为root挂载。ok，根设备就被创建了，接下来调用的函数是init/do_mounts.c:mount_block_root()，此函数又调用fs/namespace.c: sys_mount()来挂载真实的根文件系统并对其进行chdir操作。

 

最后，会返回到启动函数中，并调用init/main.c:run_init_process。调用的结果是，初始化进程开始（在这里是通过/linuxrc）。linuxrc可以是一个可执行程序，也可以是脚本（只要脚本解释器能够正常解释它）。

 

函数调用的层次关系可以从下表中看出。并不是所有与复制、挂载初始化内存盘的函数都被列举出来，这里仅仅是大概的，对整体基本流程的回顾：

init/main.c:init

init/do_mounts.c:prepare_namespace

init/do_mounts_initrd.c:initrd_load

init/do_mounts_rd.c:rd_load_image

init/do_mounts_rd.c:identify_ramdisk_image

init/do_mounts_rd.c:crd_load

lib/inflate.c:gunzip

init/do_mounts.c:mount_root

init/do_mounts.c:mount_block_root

init/do_mounts.c:do_mount_root

fs/namespace.c:sys_mount

init/main.c:run_init_process

execve

 

无盘启动的应用

 

同很多嵌入式系统的启动一样，本地磁盘（软驱或者光驱）对于启动内核和内存盘根文件系统来说，并不是必须的。DHCP工具能被用于确认网络参数，例如大家熟悉的IP抵制和子网掩码等。此外，TFTP能被用于将内核镜像以及初始化内存盘镜像传送到本地设备。一旦传输完成，linux内核就能被启动以及挂载 initrd，和本地镜像启动的过程一样。

 

让你的initrd尽可能小

 

当你在构建嵌入式系统时，总是希望initrd的镜像尽可能小，恩，这里将提供一些小技巧。首先就是使用BusyBox。前面已经提到过，BusyBox包含了很多较大的工具，通常体积都以MB计算，但是它成功得将自己的体积控制在几百KB的范围内。

 

在本例中，BusyBox镜像使用的是静态链接，因此不需要提供任何库文件。但是，如果你需要得到标准的C库文件来满足自己的二进制程序，除了大体积的 glibc库，你有其他更好的选择。第一个，小体积的uClibc库，是专门用于有空间限制的，标准C库的缩水版本。另一个适用于有空间限制环境的库是 dietlib。记住，你需要在自己的嵌入式系统中，用这些库重新编译你的二进制程序。虽然使用它们会带来一些附加的工作，但是，是值得的。

 

总结

初始化内存盘技术被创建的最初目的，是为了让内核通过一个临时的根文件系统来过渡到最终的根文件系统。initrd对于嵌入式linux系统同样是很有用处的：它能做为一个非持续性的根文件系统挂载到内存盘中。

五、

Linux攻略：让系统内存不再泄漏的好方法

内存泄漏
　　
　　
　　在此，谈论的是程序设计中内存泄漏和错误的问题，不过，并不是所有的程序都有这一问题。首先，泄漏等一些内存方面的问题在有的程序语言中是不容易发生的。这些程序语言一般都认为内存管理太重要了，所以不能由程序员来处理，最好还是由程序语言设计者来处理这些问题，这样的语言有Perl、Java等等。
　　
　　然而，在一些语言(最典型的就是C和C++)中，程序语言的设计者也认为内存管理太重要，但必需由开发人员自己来处理。内存泄漏指的是程序员动态分配了内存，但是在使用完成后却忘了将其释放。除了内存泄漏以外，在开发人员自己管理内存的开发中，缓冲溢出、悬摆指针等其它一些内存的问题也时有发生。
　　
　　
　　问题缘何产生
　　
　　
　　为了让程序能够处理在编译时无法预知的数据占用内存的大小，所以程序必需要从操作系统实时地申请内存，这就是所谓的动态内存。这时候，就会出现程序申请到内存块并且使用完成后，没有将其归还给操作系统的错误。更糟的情况是所获取的内存块的地址丢失，从而系统无法继续识别、定位该内存块。还有其它的问题，比如试图访问已经释放的指针(悬摆指针)，再如访问已经被使用了的内存(内存溢出)的问题。
　　
　　
　　后果不容忽视
　　
　　
　　对于那些不常驻内存的程序来说，由于执行过程很短，所以即使有漏洞可能也不会导致特别严重的后果。不过对于一些常驻内存的程序(比如Web服务器Apache)来说，如果出现这样的问题，后果将非常严重。因为有问题的程序会不断地向系统申请内存，并且不释放内存，最终可能导致系统内存耗尽而导致系统崩溃。此外，存在内存泄漏问题的程序除了会占用更多的内存外，还会使程序的性能急剧下降。对于服务器而言，如果出现这种情况，即使系统不崩溃，也会严重影响使用。
　　
　　悬摆指针会导致一些潜在的隐患，并且这些隐患不容易暴发。它非常不明显，因此很难被发现。在这三种存在的问题形式中，缓冲溢出可能是最危险的。事实上，它可能会导致很多安全性方面的问题(一个安全的程序包含很多要素，但是最重要的莫过于小心使用内存)。正如上面所述，有时也会发生同一内存块被多次返还给系统的问题，这显然也是程序设计上的错误。一个程序员非常希望知道在程序运行的过程中，使用内存的情况，从而能够发现并且修正问题。
　　
　　
　　如何处理
　　
　　
　　现在已经有了一些实时监测内存问题的技术。内存泄漏问题可以通过定时地终止和重启有问题的程序来发现和解决。在比较新的Linux内核版本中，有一种名为OOM(Out Of Memory )杀手的算法，它可以在必要时选择执行Killed等程序。悬摆指针可以通过定期对所有已经返还给系统的内存置零来解决。解决内存溢出问题的方法则多种多样。
　　
　　事实上，在程序运行时来解决这些问题，显然要麻烦得多，所以我们希望能够在开发程序时就发现并解决这些问题。下面介绍一些可用的自由软件。
　　
　　
　　工具一：垃圾回收器(GC)
　　
　　
　　在GCC(下载)工具包中，有一个“垃圾回收器(GC)”，它可以轻松检测并且修正很多的内存问题。目前该项目由HP的Hans-J.Boehm负责。
　　
　　使用的技术
　　
　　GC使用的是名为Boehm-Demers-Weiser的可以持续跟踪内存定位的技术。它的算法通过使用标准的内存定位函数来实现。程序使用这些函数进行编译，然后执行，算法就会分析程序的操作。该算法非常著名并且比较容易理解，不会导致问题或者对程序有任何干扰。
　　
　　性能
　　
　　该工具有很好的性能，故可以有效提高程序效率。其代码非常少并且可以直接在GCC中使用。
　　
　　该工具没有界面，使用起来比较困难，所以要想掌握它还是要花一些工夫的。一些现有的程序很有可能无法使用这个编辑器进行配置。此外，为了让所有的调用能被捕获，所有的内存调用(比如malloc()和free())都必须要使用由GC提供的相应函数来代替。我们也可以使用宏来完成这一工作，但还是觉得不够灵活。
　　
　　结论
　　
　　如果你希望能够有跨平台(体系结构、操作系统)的解决方案，那么就是它了。
　　
　　
　　工具二：Memprof
　　
　　
　　Memprof（下载）是一个非常具有吸引力且非常易于使用的软件，它由Red Hat的Owen Talyor创立。这个工具是用于GNOME前端的Boehm-Demers-Weiser垃圾回收器。
　　
　　使用的技术
　　
　　就其核心技术来说，Memprof和上面提到的GC没有什么本质的不同。不过在实现这一功能时，它是从程序中捕获所有的内存请示并且实时将其重定位到垃圾回收器。
　　
　　性能
　　
　　该工具的性能非常不错，其GUI设计得也不错(如图1所示)。这个工具直接就可以执行，并且其工作起来无需对源代码进行任何修改。在程序执行时，这个工具会以图形化的方式显示内存的使用情况，以帮助你了解程序运行过程中内存的申请情况（如图1）。

　　图1 Memprof的GUI
　　
　　
　　该工具目前只能运行于x86和PPC体系结构之上的Linux系统之中。如果你需要用于其它的平台，应该想想使用其它的工具。该工具不是GTK应用程序，所以需要一个完整的GNOME环境。这样就使得其不能灵活用于所有的地方。此外，该工具的开发工作进展得也比较缓慢(现在是0.4.1版)。
　　
　　结论
　　
　　如果你喜欢GUI工具并且不介意只能用于Linux以及GNOME之下，该工具应该可以说是非常不错。
　　
　　
　　工具三：Valgrind
　　
　　
　　Valgrind(http://developer.kde.org/~sewardj/)是一个致力于解决所有内存问题的程序，而内存泄漏只不过是其中的问题之一而已。该工具的开发人员是Julian Seward(以Bzip2和Cacheprof而闻名)。该工具宣称自己“是专门致力于解决x86 Linux中开放源代码的内存问题”，事实上，它的确做到了自己的宣言。此外，它还可以描述CPU缓存的使用情况，不过这一功能并不常用。
　　
　　使用的技术
　　
　　在这个程序中使用的技术非常复杂，不过其文档非常丰富和完整(http://developer.kde.org/~sewardj/docs/techdocs.html)。程序分配的每一字节的内存都被一个有九位的状况字跟踪，其目的是用于识别其意图。这种做法大大加重了系统的负担。
　　
　　性能
　　
　　这个工具是我们这儿介绍的三款中性能最差的一个，原因是显而易见的。该工具提供的信息细节是三个工具中最丰富的，因而速度也是最慢的。除了一些常见的问题外，该工具还可以发现内存其它的一些问题，甚至一些POSIX线程方面的问题。缓冲的信息对于大部分程序来说似乎没有必要，不过它是一个查看程序性能的很好方式。对于Valgrind来说，值得一提的就是其开发速度非常快，其开发社团也非常活跃。事实上，在Valgrind的主页上作者甚至有一句话：“如果你在使用Valgrind过程中有任何问题，请不要介意，给我发邮件吧”。
　　
　　不过，该工具是专门用于x86的。其界面是纯命令行方式，但是其可用性非常好。该工具可以直接在二进制下运行，所以在使用时并不需要对其进行重新编译。不过要熟练掌握它，还是需要使用者进行一番努力的。此外，虽然该工具曾经使用于Mozilla、OpenOffice等一些大的线程程序，但该工具对线程的支持并不完善。我想如果该工具要是有一个GUI界面，将会赢得更多人的青睐。
　　
　　结论
　　
　　如果你使用x86，对自己的代码非常了解并且不介意使用命令行方式，那么这个程序将是你的至爱。
　　
　　如果我在此介绍的三款工具你都不喜欢，那也没有关系，可在下面站点中找到很多检测内存错误的工具：http://www.sslug.dk/emailarkiv/bog/2001_08/msg00030.html。此外，还有一些商业工具，比如Purify、Geodesic等。在此就不详细介绍。