linux缺页异常

Ⅰ linux中使用了什么内存管理方法,为什么

“事实胜于雄辩”，我们用一个小例子（原形取自《User-Level Memory Management》）来展示上面所讲的各种内存区的差别与位置。

进程的地址空间对应的描述结构是“内存描述符结构”,它表示进程的全部地址空间，——包含了和进程地址空间有关的全部信息，其中当然包含进程的内存区域。

进程内存的分配与回收

创建进程fork()、程序载入execve()、映射文件mmap()、动态内存分配malloc()/brk()等进程相关操作都需要分配内存给进程。不过这时进程申请和获得的还不是实际内存，而是虚拟内存，准确的说是“内存区域”。进程对内存区域的分配最终都会归结到do_mmap（）函数上来（brk调用被单独以系统调用实现，不用do_mmap()），

内核使用do_mmap()函数创建一个新的线性地址区间。但是说该函数创建了一个新VMA并不非常准确，因为如果创建的地址区间和一个已经存在的地址区间相邻，并且它们具有相同的访问权限的话，那么两个区间将合并为一个。如果不能合并，那么就确实需要创建一个新的VMA了。但无论哪种情况，do_mmap()函数都会将一个地址区间加入到进程的地址空间中－－无论是扩展已存在的内存区域还是创建一个新的区域。

同样，释放一个内存区域应使用函数do_ummap()，它会销毁对应的内存区域。

如何由虚变实！

从上面已经看到进程所能直接操作的地址都为虚拟地址。当进程需要内存时，从内核获得的仅仅是虚拟的内存区域，而不是实际的物理地址，进程并没有获得物理内存（物理页面——页的概念请大家参考硬件基础一章），获得的仅仅是对一个新的线性地址区间的使用权。实际的物理内存只有当进程真的去访问新获取的虚拟地址时，才会由“请求页机制”产生“缺页”异常，从而进入分配实际页面的例程。

该异常是虚拟内存机制赖以存在的基本保证——它会告诉内核去真正为进程分配物理页，并建立对应的页表，这之后虚拟地址才实实在在地映射到了系统的物理内存上。（当然，如果页被换出到磁盘，也会产生缺页异常，不过这时不用再建立页表了）

这种请求页机制把页面的分配推迟到不能再推迟为止，并不急于把所有的事情都一次做完（这种思想有点像设计模式中的代理模式（proxy））。之所以能这么做是利用了内存访问的“局部性原理”，请求页带来的好处是节约了空闲内存，提高了系统的吞吐率。要想更清楚地了解请求页机制，可以看看《深入理解linux内核》一书。

这里我们需要说明在内存区域结构上的nopage操作。当访问的进程虚拟内存并未真正分配页面时，该操作便被调用来分配实际的物理页，并为该页建立页表项。在最后的例子中我们会演示如何使用该方法。

系统物理内存管理

虽然应用程序操作的对象是映射到物理内存之上的虚拟内存，但是处理器直接操作的却是物理内存。所以当应用程序访问一个虚拟地址时，首先必须将虚拟地址转化成物理地址，然后处理器才能解析地址访问请求。地址的转换工作需要通过查询页表才能完成，概括地讲，地址转换需要将虚拟地址分段，使每段虚地址都作为一个索引指向页表，而页表项则指向下一级别的页表或者指向最终的物理页面。

每个进程都有自己的页表。进程描述符的pgd域指向的就是进程的页全局目录。下面我们借用《linux设备驱动程序》中的一幅图大致看看进程地址空间到物理页之间的转换关系。

上面的过程说起来简单，做起来难呀。因为在虚拟地址映射到页之前必须先分配物理页——也就是说必须先从内核中获取空闲页，并建立页表。下面我们介绍一下内核管理物理内存的机制。

物理内存管理（页管理）

Linux内核管理物理内存是通过分页机制实现的，它将整个内存划分成无数个4k（在i386体系结构中）大小的页，从而分配和回收内存的基本单位便是内存页了。利用分页管理有助于灵活分配内存地址，因为分配时不必要求必须有大块的连续内存[3]，系统可以东一页、西一页的凑出所需要的内存供进程使用。虽然如此，但是实际上系统使用内存时还是倾向于分配连续的内存块，因为分配连续内存时，页表不需要更改，因此能降低TLB的刷新率（频繁刷新会在很大程度上降低访问速度）。

鉴于上述需求，内核分配物理页面时为了尽量减少不连续情况，采用了“伙伴”关系来管理空闲页面。伙伴关系分配算法大家应该不陌生——几乎所有操作系统方面的书都会提到,我们不去详细说它了，如果不明白可以参看有关资料。这里只需要大家明白Linux中空闲页面的组织和管理利用了伙伴关系，因此空闲页面分配时也需要遵循伙伴关系，最小单位只能是2的幂倍页面大小。内核中分配空闲页面的基本函数是get_free_page/get_free_pages，它们或是分配单页或是分配指定的页面（2、4、8…512页）。

注意：get_free_page是在内核中分配内存，不同于malloc在用户空间中分配，malloc利用堆动态分配，实际上是调用brk()系统调用，该调用的作用是扩大或缩小进程堆空间（它会修改进程的brk域）。如果现有的内存区域不够容纳堆空间，则会以页面大小的倍数为单位，扩张或收缩对应的内存区域，但brk值并非以页面大小为倍数修改，而是按实际请求修改。因此Malloc在用户空间分配内存可以以字节为单位分配,但内核在内部仍然会是以页为单位分配的。

另外,需要提及的是，物理页在系统中由页结构structpage描述，系统中所有的页面都存储在数组mem_map[]中，可以通过该数组找到系统中的每一页（空闲或非空闲）。而其中的空闲页面则可由上述提到的以伙伴关系组织的空闲页链表（free_area[MAX_ORDER]）来索引。

内核内存使用

Slab

所谓尺有所长，寸有所短。以页为最小单位分配内存对于内核管理系统中的物理内存来说的确比较方便，但内核自身最常使用的内存却往往是很小（远远小于一页）的内存块——比如存放文件描述符、进程描述符、虚拟内存区域描述符等行为所需的内存都不足一页。这些用来存放描述符的内存相比页面而言，就好比是面包屑与面包。一个整页中可以聚集多个这些小块内存；而且这些小块内存块也和面包屑一样频繁地生成/销毁。

为了满足内核对这种小内存块的需要，Linux系统采用了一种被称为slab分配器的技术。Slab分配器的实现相当复杂，但原理不难，其核心思想就是“存储池[4]”的运用。内存片段（小块内存）被看作对象，当被使用完后，并不直接释放而是被缓存到“存储池”里，留做下次使用，这无疑避免了频繁创建与销毁对象所带来的额外负载。

Slab技术不但避免了内存内部分片（下文将解释）带来的不便（引入Slab分配器的主要目的是为了减少对伙伴系统分配算法的调用次数——频繁分配和回收必然会导致内存碎片——难以找到大块连续的可用内存），而且可以很好地利用硬件缓存提高访问速度。

Slab并非是脱离伙伴关系而独立存在的一种内存分配方式，slab仍然是建立在页面基础之上，换句话说，Slab将页面（来自于伙伴关系管理的空闲页面链表）撕碎成众多小内存块以供分配，slab中的对象分配和销毁使用kmem_cache_alloc与kmem_cache_free。

Kmalloc

Slab分配器不仅仅只用来存放内核专用的结构体，它还被用来处理内核对小块内存的请求。当然鉴于Slab分配器的特点，一般来说内核程序中对小于一页的小块内存的请求才通过Slab分配器提供的接口Kmalloc来完成（虽然它可分配32到131072字节的内存）。从内核内存分配的角度来讲，kmalloc可被看成是get_free_page（s）的一个有效补充，内存分配粒度更灵活了。

有兴趣的话，可以到/proc/slabinfo中找到内核执行现场使用的各种slab信息统计，其中你会看到系统中所有slab的使用信息。从信息中可以看到系统中除了专用结构体使用的slab外，还存在大量为Kmalloc而准备的Slab（其中有些为dma准备的）。

内核非连续内存分配（Vmalloc）

伙伴关系也好、slab技术也好，从内存管理理论角度而言目的基本是一致的，它们都是为了防止“分片”，不过分片又分为外部分片和内部分片之说，所谓内部分片是说系统为了满足一小段内存区（连续）的需要，不得不分配了一大区域连续内存给它，从而造成了空间浪费；外部分片是指系统虽有足够的内存，但却是分散的碎片，无法满足对大块“连续内存”的需求。无论何种分片都是系统有效利用内存的障碍。slab分配器使得一个页面内包含的众多小块内存可独立被分配使用，避免了内部分片，节约了空闲内存。伙伴关系把内存块按大小分组管理，一定程度上减轻了外部分片的危害，因为页框分配不在盲目，而是按照大小依次有序进行，不过伙伴关系只是减轻了外部分片，但并未彻底消除。你自己比划一下多次分配页面后，空闲内存的剩余情况吧。

所以避免外部分片的最终思路还是落到了如何利用不连续的内存块组合成“看起来很大的内存块”——这里的情况很类似于用户空间分配虚拟内存，内存逻辑上连续，其实映射到并不一定连续的物理内存上。Linux内核借用了这个技术，允许内核程序在内核地址空间中分配虚拟地址，同样也利用页表（内核页表）将虚拟地址映射到分散的内存页上。以此完美地解决了内核内存使用中的外部分片问题。内核提供vmalloc函数分配内核虚拟内存，该函数不同于kmalloc，它可以分配较Kmalloc大得多的内存空间（可远大于128K，但必须是页大小的倍数），但相比Kmalloc来说,Vmalloc需要对内核虚拟地址进行重映射，必须更新内核页表，因此分配效率上要低一些（用空间换时间）

与用户进程相似,内核也有一个名为init_mm的mm_strcut结构来描述内核地址空间，其中页表项pdg=swapper_pg_dir包含了系统内核空间（3G-4G）的映射关系。因此vmalloc分配内核虚拟地址必须更新内核页表，而kmalloc或get_free_page由于分配的连续内存，所以不需要更新内核页表。

vmalloc分配的内核虚拟内存与kmalloc/get_free_page分配的内核虚拟内存位于不同的区间，不会重叠。因为内核虚拟空间被分区管理，各司其职。进程空间地址分布从0到3G(其实是到PAGE_OFFSET,在0x86中它等于0xC0000000)，从3G到vmalloc_start这段地址是物理内存映射区域（该区域中包含了内核镜像、物理页面表mem_map等等）比如我使用的系统内存是64M(可以用free看到)，那么(3G——3G+64M)这片内存就应该映射到物理内存，而vmalloc_start位置应在3G+64M附近（说"附近"因为是在物理内存映射区与vmalloc_start期间还会存在一个8M大小的gap来防止跃界）,vmalloc_end的位置接近4G(说"接近"是因为最后位置系统会保留一片128k大小的区域用于专用页面映射，还有可能会有高端内存映射区，这些都是细节，这里我们不做纠缠)。

上图是内存分布的模糊轮廓

由get_free_page或Kmalloc函数所分配的连续内存都陷于物理映射区域，所以它们返回的内核虚拟地址和实际物理地址仅仅是相差一个偏移量（PAGE_OFFSET），你可以很方便的将其转化为物理内存地址，同时内核也提供了virt_to_phys（）函数将内核虚拟空间中的物理映射区地址转化为物理地址。要知道，物理内存映射区中的地址与内核页表是有序对应的，系统中的每个物理页面都可以找到它对应的内核虚拟地址（在物理内存映射区中的）。

而vmalloc分配的地址则限于vmalloc_start与vmalloc_end之间。每一块vmalloc分配的内核虚拟内存都对应一个vm_struct结构体（可别和vm_area_struct搞混，那可是进程虚拟内存区域的结构），不同的内核虚拟地址被4k大小的空闲区间隔，以防止越界——见下图）。与进程虚拟地址的特性一样，这些虚拟地址与物理内存没有简单的位移关系，必须通过内核页表才可转换为物理地址或物理页。它们有可能尚未被映射，在发生缺页时才真正分配物理页面。

这里给出一个小程序帮助大家认清上面几种分配函数所对应的区域。

#include<linux/mole.h>

#include<linux/slab.h>

#include<linux/vmalloc.h>

unsignedchar*pagemem;

unsignedchar*kmallocmem;

unsignedchar*vmallocmem;

intinit_mole(void)

{

pagemem = get_free_page(0);

printk("<1>pagemem=%s",pagemem);

kmallocmem = kmalloc(100,0);

printk("<1>kmallocmem=%s",kmallocmem);

vmallocmem = vmalloc(1000000);

printk("<1>vmallocmem=%s",vmallocmem);

}

voidcleanup_mole(void)

{

free_page(pagemem);

kfree(kmallocmem);

vfree(vmallocmem);

}

实例

内存映射(mmap)是Linux操作系统的一个很大特色，它可以将系统内存映射到一个文件（设备）上，以便可以通过访问文件内容来达到访问内存的目的。这样做的最大好处是提高了内存访问速度，并且可以利用文件系统的接口编程（设备在Linux中作为特殊文件处理）访问内存，降低了开发难度。许多设备驱动程序便是利用内存映射功能将用户空间的一段地址关联到设备内存上，无论何时，只要内存在分配的地址范围内进行读写，实际上就是对设备内存的访问。同时对设备文件的访问也等同于对内存区域的访问，也就是说，通过文件操作接口可以访问内存。Linux中的X服务器就是一个利用内存映射达到直接高速访问视频卡内存的例子。

熟悉文件操作的朋友一定会知道file_operations结构中有mmap方法，在用户执行mmap系统调用时，便会调用该方法来通过文件访问内存——不过在调用文件系统mmap方法前，内核还需要处理分配内存区域（vma_struct）、建立页表等工作。对于具体映射细节不作介绍了，需要强调的是,建立页表可以采用remap_page_range方法一次建立起所有映射区的页表，或利用vma_struct的nopage方法在缺页时现场一页一页的建立页表。第一种方法相比第二种方法简单方便、速度快，但是灵活性不高。一次调用所有页表便定型了，不适用于那些需要现场建立页表的场合——比如映射区需要扩展或下面我们例子中的情况。

我们这里的实例希望利用内存映射，将系统内核中的一部分虚拟内存映射到用户空间，以供应用程序读取——你可利用它进行内核空间到用户空间的大规模信息传输。因此我们将试图写一个虚拟字符设备驱动程序，通过它将系统内核空间映射到用户空间——将内核虚拟内存映射到用户虚拟地址。从上一节已经看到Linux内核空间中包含两种虚拟地址：一种是物理和逻辑都连续的物理内存映射虚拟地址；另一种是逻辑连续但非物理连续的vmalloc分配的内存虚拟地址。我们的例子程序将演示把vmalloc分配的内核虚拟地址映射到用户地址空间的全过程。

程序里主要应解决两个问题：

第一是如何将vmalloc分配的内核虚拟内存正确地转化成物理地址？

因为内存映射先要获得被映射的物理地址，然后才能将其映射到要求的用户虚拟地址上。我们已经看到内核物理内存映射区域中的地址可以被内核函数virt_to_phys转换成实际的物理内存地址，但对于vmalloc分配的内核虚拟地址无法直接转化成物理地址，所以我们必须对这部分虚拟内存格外“照顾”——先将其转化成内核物理内存映射区域中的地址，然后在用virt_to_phys变为物理地址。

转化工作需要进行如下步骤：

如下图所示：

第二是当访问vmalloc分配区时，如果发现虚拟内存尚未被映射到物理页，则需要处理“缺页异常”。因此需要我们实现内存区域中的nopaga操作，以能返回被映射的物理页面指针，在我们的实例中就是返回上面过程中的内核物理内存映射区域中的地址。由于vmalloc分配的虚拟地址与物理地址的对应关系并非分配时就可确定，必须在缺页现场建立页表，因此这里不能使用remap_page_range方法，只能用vma的nopage方法一页一页的建立。

程序组成

map_driver.c，它是以模块形式加载的虚拟字符驱动程序。该驱动负责将一定长的内核虚拟地址(vmalloc分配的)映射到设备文件上。其中主要的函数有——vaddress_to_kaddress（）负责对vmalloc分配的地址进行页表解析,以找到对应的内核物理映射地址（kmalloc分配的地址）；map_nopage()负责在进程访问一个当前并不存在的VMA页时，寻找该地址对应的物理页，并返回该页的指针。

test.c它利用上述驱动模块对应的设备文件在用户空间读取读取内核内存。结果可以看到内核虚拟地址的内容（ok!），被显示在了屏幕上。

执行步骤

编译map_driver.c为map_driver.o模块,具体参数见Makefile

加载模块：insmodmap_driver.o

生成对应的设备文件

1在/proc/devices下找到map_driver对应的设备命和设备号：grepmapdrv/proc/devices

2建立设备文件mknodmapfilec 254 0（在我的系统里设备号为254）

利用maptest读取mapfile文件，将取自内核的信息打印到屏幕上。

Ⅱ linux kernel可不可以完成进程调度

操作系统要实现多进程，进程调度必不可少。 有人说，进程调度是操作系统中最为重要的一个部分。我觉得这种说法说得太绝对了一点，就像很多人动辄就说"某某函数比某某函数效率高XX倍"一样，脱离了实际环境，这些结论是比较片面的。 而进程调度究竟有多重要呢? 首先，我们需要明确一点：进程调度是对TASK_RUNNING状态的进程进行调度(参见《linux进程状态浅析》)。如果进程不可执行(正在睡眠或其他)，那么它跟进程调度没多大关系。 所以，如果你的系统负载非常低，盼星星盼月亮才出现一个可执行状态的进程。那么进程调度也就不会太重要。哪个进程可执行，就让它执行去，没有什么需要多考虑的。 反之，如果系统负载非常高，时时刻刻都有N多个进程处于可执行状态，等待被调度运行。那么进程调度程序为了协调这N个进程的执行，必定得做很多工作。协调得不好，系统的性能就会大打折扣。这个时候，进程调度就是非常重要的。 尽管我们平常接触的很多计算机(如桌面系统、网络服务器、等)负载都比较低，但是linux作为一个通用操作系统，不能假设系统负载低，必须为应付高负载下的进程调度做精心的设计。 当然，这些设计对于低负载(且没有什么实时性要求)的环境，没多大用。极端情况下，如果CPU的负载始终保持0或1(永远都只有一个进程或没有进程需要在CPU上运行)，那么这些设计基本上都是徒劳的。 优先级 现在的操作系统为了协调多个进程的“同时”运行，最基本的手段就是给进程定义优先级。定义了进程的优先级，如果有多个进程同时处于可执行状态，那么谁优先级高谁就去执行，没有什么好纠结的了。 那么，进程的优先级该如何确定呢?有两种方式：由用户程序指定、由内核的调度程序动态调整。(下面会说到) linux内核将进程分成两个级别：普通进程和实时进程。实时进程的优先级都高于普通进程，除此之外，它们的调度策略也有所不同。 实时进程的调度 实时，原本的涵义是“给定的操作一定要在确定的时间内完成”。重点并不在于操作一定要处理得多快，而是时间要可控(在最坏情况下也不能突破给定的时间)。 这样的“实时”称为“硬实时”，多用于很精密的系统之中(比如什么火箭、导弹之类的)。一般来说，硬实时的系统是相对比较专用的。 像linux这样的通用操作系统显然没法满足这样的要求，中断处理、虚拟内存、等机制的存在给处理时间带来了很大的不确定性。硬件的cache、磁盘寻道、总线争用、也会带来不确定性。 比如考虑“i++;”这么一句C代码。绝大多数情况下，它执行得很快。但是极端情况下还是有这样的可能： 1、i的内存空间未分配，CPU触发缺页异常。而linux在缺页异常的处理代码中试图分配内存时，又可能由于系统内存紧缺而分配失败，导致进程进入睡眠; 2、代码执行过程中硬件产生中断，linux进入中断处理程序而搁置当前进程。而中断处理程序的处理过程中又可能发生新的硬件中断，中断永远嵌套不止……; 等等…… 而像linux这样号称实现了“实时”的通用操作系统，其实只是实现了“软实时”，即尽可能地满足进程的实时需求。 如果一个进程有实时需求(它是一个实时进程)，则只要它是可执行状态的，内核就一直让它执行，以尽可能地满足它对CPU的需要，直到它完成所需要做的事情，然后睡眠或退出(变为非可执行状态)。 而如果有多个实时进程都处于可执行状态，则内核会先满足优先级最高的实时进程对CPU的需要，直到它变为非可执行状态。 于是，只要高优先级的实时进程一直处于可执行状态，低优先级的实时进程就一直不能得到CPU;只要一直有实时进程处于可执行状态，普通进程就一直不能得到CPU。 那么，如果多个相同优先级的实时进程都处于可执行状态呢?这时就有两种调度策略可供选择： 1、SCHED_FIFO：先进先出。直到先被执行的进程变为非可执行状态，后来的进程才被调度执行。在这种策略下，先来的进程可以执行sched_yield系统调用，自愿放弃CPU，以让权给后来的进程; 2、SCHED_RR：轮转调度。内核为实时进程分配时间片，在时间片用完时，让下一个进程使用CPU; 强调一下，这两种调度策略以及sched_yield系统调用都仅仅针对于相同优先级的多个实时进程同时处于可执行状态的情况。 在linux下，用户程序可以通过sched_setscheler系统调用来设置进程的调度策略以及相关调度参数;sched_setparam系统调用则只用于设置调度参数。这两个系统调用要求用户进程具有设置进程优先级的能力(CAP_SYS_NICE，一般来说需要root权限)(参阅capability相关的文章)。 通过将进程的策略设为SCHED_FIFO或SCHED_RR，使得进程变为实时进程。而进程的优先级则是通过以上两个系统调用在设置调度参数时指定的。 对于实时进程，内核不会试图调整其优先级。因为进程实时与否?有多实时?这些问题都是跟用户程序的应用场景相关，只有用户能够回答，内核不能臆断。 综上所述，实时进程的调度是非常简单的。进程的优先级和调度策略都由用户定死了，内核只需要总是选择优先级最高的实时进程来调度执行即可。唯一稍微麻烦一点的只是在选择具有相同优先级的实时进程时，要考虑两种调度策略。 普通进程的调度 实时进程调度的中心思想是，让处于可执行状态的最高优先级的实时进程尽可能地占有CPU，因为它有实时需求;而普通进程则被认为是没有实时需求的进程，于是调度程序力图让各个处于可执行状态的普通进程和平共处地分享CPU，从而让用户觉得这些进程是同时运行的。 与实时进程相比，普通进程的调度要复杂得多。内核需要考虑两件麻烦事： 一、动态调整进程的优先级 按进程的行为特征，可以将进程分为“交互式进程”和“批处理进程”： 交互式进程(如桌面程序、服务器、等)主要的任务是与外界交互。这样的进程应该具有较高的优先级，它们总是睡眠等待外界的输入。而在输入到来，内核将其唤醒时，它们又应该很快被调度执行，以做出响应。比如一个桌面程序，如果鼠标点击后半秒种还没反应，用户就会感觉系统“卡”了; 批处理进程(如编译程序)主要的任务是做持续的运算，因而它们会持续处于可执行状态。这样的进程一般不需要高优先级，比如编译程序多运行了几秒种，用户多半不会太在意; 如果用户能够明确知道进程应该有怎样的优先级，可以通过nice、setpriority系统调用来对优先级进行设置。(如果要提高进程的优先级，要求用户进程具有CAP_SYS_NICE能力。) 然而应用程序未必就像桌面程序、编译程序这样典型。程序的行为可能五花八门，可能一会儿像交互式进程，一会儿又像批处理进程。以致于用户难以给它设置一个合适的优先级。 再者，即使用户明确知道一个进程是交互式还是批处理，也多半碍于权限或因为偷懒而不去设置进程的优先级。(你又是否为某个程序设置过优先级呢?) 于是，最终，区分交互式进程和批处理进程的重任就落到了内核的调度程序上。 调度程序关注进程近一段时间内的表现(主要是检查其睡眠时间和运行时间)，根据一些经验性的公式，判断它现在是交互式的还是批处理的?程度如何?最后决定给它的优先级做一定的调整。 进程的优先级被动态调整后，就出现了两个优先级： 1、用户程序设置的优先级(如果未设置，则使用默认值)，称为静态优先级。这是进程优先级的基准，在进程执行的过程中往往是不改变的; 2、优先级动态调整后，实际生效的优先级。这个值是可能时时刻刻都在变化的; 二、调度的公平性 在支持多进程的系统中，理想情况下，各个进程应该是根据其优先级公平地占有CPU。而不会出现“谁运气好谁占得多”这样的不可控的情况。 linux实现公平调度基本上是两种思路： 1、给处于可执行状态的进程分配时间片(按照优先级)，用完时间片的进程被放到“过期队列”中。等可执行状态的进程都过期了，再重新分配时间片; 2、动态调整进程的优先级。随着进程在CPU上运行，其优先级被不断调低，以便其他优先级较低的进程得到运行机会; 后一种方式有更小的调度粒度，并且将“公平性”与“动态调整优先级”两件事情合而为一，大大简化了内核调度程序的代码。因此，这种方式也成为内核调度程序的新宠。 强调一下，以上两点都是仅针对普通进程的。而对于实时进程，内核既不能自作多情地去动态调整优先级，也没有什么公平性可言。 普通进程具体的调度算法非常复杂，并且随linux内核版本的演变也在不断更替(不仅仅是简单的调整)，所以本文就不继续深入了。 调度程序的效率 “优先级”明确了哪个进程应该被调度执行，而调度程序还必须要关心效率问题。调度程序跟内核中的很多过程一样会频繁被执行，如果效率不济就会浪费很多CPU时间，导致系统性能下降。 在linux 2.4时，可执行状态的进程被挂在一个链表中。每次调度，调度程序需要扫描整个链表，以找出最优的那个进程来运行。复杂度为O(n); 在linux 2.6早期，可执行状态的进程被挂在N(N=140)个链表中，每一个链表代表一个优先级，系统中支持多少个优先级就有多少个链表。每次调度，调度程序只需要从第一个不为空的链表中取出位于链表头的进程即可。这样就大大提高了调度程序的效率，复杂度为O(1); 在linux 2.6近期的版本中，可执行状态的进程按照优先级顺序被挂在一个红黑树(可以想象成平衡二叉树)中。每次调度，调度程序需要从树中找出优先级最高的进程。复杂度为O(logN)。 那么，为什么从linux 2.6早期到近期linux 2.6版本，调度程序选择进程时的复杂度反而增加了呢? 这是因为，与此同时，调度程序对公平性的实现从上面提到的第一种思路改变为第二种思路(通过动态调整优先级实现)。而O(1)的算法是基于一组数目不大的链表来实现的，按我的理解，这使得优先级的取值范围很小(区分度很低)，不能满足公平性的需求。而使用红黑树则对优先级的取值没有限制(可以用32位、64位、或更多位来表示优先级的值)，并且O(logN)的复杂度也还是很高效的。 调度触发的时机 调度的触发主要有如下几种情况： 1、当前进程(正在CPU上运行的进程)状态变为非可执行状态。 进程执行系统调用主动变为非可执行状态。比如执行nanosleep进入睡眠、执行exit退出、等等; 进程请求的资源得不到满足而被迫进入睡眠状态。比如执行read系统调用时，磁盘高速缓存里没有所需要的数据，从而睡眠等待磁盘IO; 进程响应信号而变为非可执行状态。比如响应SIGSTOP进入暂停状态、响应SIGKILL退出、等等; 2、抢占。进程运行时，非预期地被剥夺CPU的使用权。这又分两种情况：进程用完了时间片、或出现了优先级更高的进程。 优先级更高的进程受正在CPU上运行的进程的影响而被唤醒。如发送信号主动唤醒，或因为释放互斥对象(如释放锁)而被唤醒; 内核在响应时钟中断的过程中，发现当前进程的时间片用完; 内核在响应中断的过程中，发现优先级更高的进程所等待的外部资源的变为可用，从而将其唤醒。比如CPU收到网卡中断，内核处理该中断，发现某个socket可读，于是唤醒正在等待读这个socket的进程;再比如内核在处理时钟中断的过程中，触发了定时器，从而唤醒对应的正在nanosleep系统调用中睡眠的进程。 所有任务都采用linux分时调度策略时： 1，创建任务指定采用分时调度策略，并指定优先级nice值(-20~19)。 2，将根据每个任务的nice值确定在cpu上的执行时间(counter)。 3，如果没有等待资源，则将该任务加入到就绪队列中。 4，调度程序遍历就绪队列中的任务，通过对每个任务动态优先级的计算权值(counter+20-nice)结果，选择计算结果最大的一个去运行，当这个时间片用完后(counter减至0)或者主动放弃cpu时，该任务将被放在就绪队列末尾(时间片用完)或等待队列(因等待资源而放弃cpu)中。 5，此时调度程序重复上面计算过程，转到第4步。 6，当调度程序发现所有就绪任务计算所得的权值都为不大于0时，重复第2步。 所有任务都采用FIFO时： 1，创建进程时指定采用FIFO，并设置实时优先级rt_priority(1-99)。 2，如果没有等待资源，则将该任务加入到就绪队列中。 3，调度程序遍历就绪队列，根据实时优先级计算调度权值(1000+rt_priority),选择权值最高的任务使用cpu，该FIFO任务将一直占有cpu直到有优先级更高的任务就绪(即使优先级相同也不行)或者主动放弃(等待资源)。 4，调度程序发现有优先级更高的任务到达(高优先级任务可能被中断或定时器任务唤醒，再或被当前运行的任务唤醒，等等)，则调度程序立即在当前任务堆栈中保存当前cpu寄存器的所有数据，重新从高优先级任务的堆栈中加载寄存器数据到cpu，此时高优先级的任务开始运行。重复第3步。 5，如果当前任务因等待资源而主动放弃cpu使用权，则该任务将从就绪队列中删除，加入等待队列，此时重复第3步。 所有任务都采用RR调度策略时： 1，创建任务时指定调度参数为RR，并设置任务的实时优先级和nice值(nice值将会转换为该任务的时间片的长度)。 2，如果没有等待资源，则将该任务加入到就绪队列中。 3，调度程序遍历就绪队列，根据实时优先级计算调度权值(1000+rt_priority),选择权值最高的任务使用cpu。 4，如果就绪队列中的RR任务时间片为0，则会根据nice值设置该任务的时间片，同时将该任务放入就绪队列的末尾。重复步骤3。 5，当前任务由于等待资源而主动退出cpu，则其加入等待队列中。重复步骤3。 系统中既有分时调度，又有时间片轮转调度和先进先出调度： 1，RR调度和FIFO调度的进程属于实时进程，以分时调度的进程是非实时进程。 2，当实时进程准备就绪后，如果当前cpu正在运行非实时进程，则实时进程立即抢占非实时进程。 3，RR进程和FIFO进程都采用实时优先级做为调度的权值标准，RR是FIFO的一个延伸。FIFO时，如果两个进程的优先级一样，则这两个优先级一样的进程具体执行哪一个是由其在队列中的未知决定的，这样导致一些不公正性(优先级是一样的，为什么要让你一直运行?),如果将两个优先级一样的任务的调度策略都设为RR,则保证了这两个任务可以循环执行，保证了公平。 Ingo Molnar-实时补丁 为了能并入主流内核，Ingo Molnar的实时补丁也采用了非常灵活的策略，它支持四种抢占模式： 1.No Forced Preemption (Server)，这种模式等同于没有使能抢占选项的标准内核，主要适用于科学计算等服务器环境。 2.Voluntary Kernel Preemption (Desktop)，这种模式使能了自愿抢占，但仍然失效抢占内核选项，它通过增加抢占点缩减了抢占延迟，因此适用于一些需要较好的响应性的环境，如桌面环境，当然这种好的响应性是以牺牲一些吞吐率为代价的。 3.Preemptible Kernel (Low-Latency Desktop)，这种模式既包含了自愿抢占，又使能了可抢占内核选项，因此有很好的响应延迟，实际上在一定程度上已经达到了软实时性。它主要适用于桌面和一些嵌入式系统，但是吞吐率比模式2更低。 4.Complete Preemption (Real-Time)，这种模式使能了所有实时功能，因此完全能够满足软实时需求，它适用于延迟要求为100微秒或稍低的实时系统。 实现实时是以牺牲系统的吞吐率为代价的，因此实时性越好，系统吞吐率就越低。

Ⅲ 详解Linux系统内存知识及调优方案

内存是计算机中重要的部件之一，它是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大。内存作用是用于暂时存放CPU中的运算数据，以及与硬盘等外部存储器交换的数据。只要计算机在运行中，CPU就会把需要运算的数据调到内存中进行运算，当运算完成后CPU再将结果传送出来，内存的运行也决定了计算机的稳定运行。对于整个操作系统来说，内存可能是最麻烦的的设备。而其性能的好坏直接影响着整个操作系统。

我们知道CPU是不能与硬盘打交道的，只有数据被载入到内存中才可以被CPU调用。cpu在访问内存的时候需要先像内存监控程序请求，由监控程序控制和分配内存的读写请求，这个监控程序叫做MMU(内存管理单元)。下面以32位系统来说明内存的访问过程：

32位的系统上每一个进程在访问内存的时候，每一个进程都当做自己有4个G的内存空间可用，这叫虚拟内存(地址)，虚拟内存转化成物理内存是通过MMU来完成的。为了能够从线性地址转换成物理地址，需要page table(页表)的内存空间,page table要载入到MMU上。为了完成线性地址到物理地址的映射，如果按照1个字节1个字节映射的话，需要一张非常大的表，这种转换关系会非常的复杂。因此把内存空间又划分成了另外一种存储单元格式，通常为4K。在不同的硬件平台上，它们的大小一般是不一样的，像x86 32位的有4k的页;而64位的有4k页，2M页，4M页，8M页等等，默认都是4k的。每一个进程一般而言都有自己的页路径和页表映射机制，不管那一个页表都是由内核加载的。每一个进程只能看到自己的线性地址空间，想要增加新的内存的时候，只能在自己的线性地址空间中申请，并且申请后一定是通过操作系统的内核映射到物理地址空间中去找那么一段空间，并且告诉线性地址空间准备好了，可以访问，并且在page table中增加一条映射关系，于是就可以访问物理内存了，这种叫做内存分配。但是新的申请一定是通过操作的内核到物理内存中去找那么一段空间，并且告诉线性地址空间好了，可以建设映射关系，最终page table建立映射关系。

这反映了上述描述过程的大体情况。可以看到每一个用户程序都会有自己的页表，并且映射到对应的主存储器上去。

根据上述文字和图表的描述可以发现2个问题：

1.每个进程如果需要访问内存的时候都需要去查找page table的话，势必会造成服务器的性能底下

2.如果主存储器的内存满了以后，应用程序还需要调用内存的时候怎么办

对于第一个问题，我们就需要借助TLB(Translation Lookaside Buffer)翻译后备缓冲器。TLB是一个内存管理单元，它可以用于改进虚拟地址到物理地址转换速度的缓存。这样每次在查找page table的时候就可以先去TLB中查找相应的页表数据，如果有就直接返回，没有再去查找page table，并把查找到的结果缓存中TLB中。TLB虽然解决了缓存的功能，但是在那么page table中查找映射关系仍然很慢，所以又有了page table的分级目录。page table可以分为1级目录，2级目录和偏移量

但是一个进程在运行的时候要频繁的打开文件，关闭文件。这就意味着要频繁的申请内存和释放内存。有些能够在内存中缓存数据的那些进程，他们对内存的分配和回收更多，那么每一次分配都会在页表中建立一个对应项。所以，就算内存的速度很快，大量频繁的同一时间分配和释放内存，依然会降低服务器的整体性能。当然内存空间不够用的时候，我们称为oom(out of memory,内存耗尽)。当内存耗尽的时候，，整个操作系统挂了。这种情况下我们可以考虑交换分区，交换分区毕竟是由硬盘虚拟出来的内存，所以其性能与真正的内存相比，差了很多，所以要尽力避免使用交换分区。有物理内存空间的时候尽量保证全部使用物理内存。cpu无论如何是不能给交换内存打交道的，它也只能给物理内存打交道，能寻址的空间也只能是物理内存。所以当真正物理内存空间不够用的时候，会通过LRU算法把其中最近最少使用的内存放到交换内存中去，这样物理内存中的那段空间就可以供新的程序使用了。但是这样会引发另外的一个问题，即原来的进程通过page table寻找的时候，那一段空间的数据已经不属于它了。所以此刻cpu发送通知或者异常告诉这个程序，这个地址空间已不属于它，这个时候可能会出现2种情况：

1.物理内存有可用的空间可用：这个时候cpu会根据以前的转换策略会把交换分区中的那段内存重新送到物理内存中去，但是转换过来的空间地址不一定会是以前的那一段空间地址，因为以前的那一段空间地址可能已经被别人使用了。

2.物理内存没有可用的空间可用：这个时候依然会使用LRU算发把当前物理地址空间上最近最少使用的空间地址转换到交换内存中去，并把当前进程需要的这断在交换空间中的内存送到物理内存空间中去，并且重新建立映射关系。

上述通知或者异常出现的情况，通常叫做缺页异常。缺页异常也分为大异常和小异常两种。大异常就是访问的数据内存中没有，不的不去硬盘上加载，无论是从交换内存中还是直接从磁盘的某个文件系统上，反正需要从硬盘上去加载，这种异常加载需要很长时间。小异常就是进程之间通过共享内存，第二个进程访问的时候，查看本地的内存映射表没有，但是其它进程已经拥有了这个内存页，所以可以直接映射，这种异常加载需要的时间一般很短。

在操作系统开机的时候，每一个io设备都会像cpu申请一些列的随机端口，这种端口叫做io端口。在IBM PC体系结构中，I/O地址空间一共提供了65,536个8位的I/O端口。正是这些io端口的存在，cpu可以与io设备进行读写交互的过程。在执行读写操作时，CPU使用地址总线选择所请求的I/O端口，使用数据总线在CPU寄存器和端口之间传送数据。I/O端口还可以被映射到物理地址空间：因此，处理器和I/O设备之间的通信就可以直接使用对内存进行操作的汇编语言指令(例如，mov、and、or等等)。现代的硬件设备更倾向于映射I/O，因为这样处理的速度较快，并可以和DMA结合起来使用。这样io在和内存传数据的时候就不需要通过cpu，cpu把总线的控制权交给DMA，每次io传数据的时候就调用DMA一次，就把cpu给解放了出来。当数据传输完了以后，DMA通知给cpu中断一次。DMA在运行的时候对整个总线有控制权限，当cpu发现有其它进程需要使用总线的时候，二者就会产生争用。这个时候，在总线控制权的使用上，CPU和DMA具有相等的权限。只要CPU委托给了DMA，就不能随意的收回这个委托，就要等待DMA的用完。

如果没有其它进程可以运行，或者其它进程运行的时间非常短，这个时候CPU发现我们的IO仍然没有完成，那就意味着，CPU只能等待IO了。CPU在时间分配里面有个iowait的值，就是CPU在等待IO花费的时间。有些是在同步调用过程中，CPU必须要等待IO的完成;否者CPU可以释放IO的传输在背后自动完成，CPU自己去处理其它的事情。等硬盘数据传输完成以后，硬盘只需要像CPU发起一个通知即可。CPU外围有一种设备，这个设备叫做可编程中断控制器。每一个硬件设备为了给CPU通信，在刚开机的时候，在BIOS实现检测的时候，这个设备就要到可编程中断控制器上去注册一个所谓的中断号。那么这个号码就归这个硬件使用了。当前主机上可能有多个硬件，每一个硬件都有自己的号码，CPU在收到中断号以后，就能够通过中断相量表查找到那个硬件设备进行中断。并且就由对应的IO端口过来处理了。

CPU正在运行其它进程，当一个中断请求发过来的时候，CPU会立即终止当前正在处理的进程，而去处理中断。当前CPU挂起当前正在处理的进程，转而去执行中断的过程，也叫做中断切换。只不过，这种切换在量级别上比进程切换要低一些，而且任何中断的优先级通常比任何进程也要高，因为我们指的是硬件中断。中断还分为上半部和下半部，一般而言，上半部就是CPU在处理的时候，把它接进来，放到内存中，如果这个事情不是特别紧急(CPU或者内核会自己判断)，因此在这种情况下，CPU回到现场继续执行刚才挂起的进程，当这个进程处理完了，再回过头来执行中断的下半部分。

在32位系统中，我们的内存(线性地址)地址空间中，一般而言，低地址空间有一个G是给内核使用的，上面3个G是给进程使用的。但是应该明白，其实在内核内存当中，再往下，不是直接这样划分的。32位系统和64位系统可能不一样(物理地址)，在32位系统中，最低端有那么10多M的空间是给DMA使用的。DNA的总线宽度是很小的，可能只有几位，所以寻址能力很有限，访问的内存空间也就很有限。如果DMA需要复制数据，而且自己能够寻址物理内存，还可以把数据直接壮哉进内存中去，那么就必须保证DMA能够寻址那段内存才行。寻址的前提就是把最低地址断M，DA的寻址范围内的那一段给了DMA。所以站在这个角度来说，我们的内存管理是分区域的。

在32位系统上，16M的内存空间给了ZONE_DMA(DMA使用的物理地址空间);从16M到896M给了ZONE_NORMAL(正常物理地址空间)，对于Linux操作系统来说，是内核可以直接访问的地址空间;从896M到1G这断空间叫做"Reserved"(预留的物理地址空间);从1G到4G的这段物理地址空间中，我们的内核是不能直接访问的，要想访问必须把其中的一段内容映射到Reserved来，在Reserved中保留出那一段内存的地址编码，我们内核才能上去访问，所以内核不直接访问大于1G的物理地址空间。所以在32位系统上，它访问内存当中的数据，中间是需要一个额外步骤的。

在64位系统上，ZONE_DAM给了低端的1G地址空间，这个时候DMA的寻址能力被大大加强了;ZONE_DAM32可以使用4G的空间;而大于1G以上给划分了ZONE_NORMAL,这段空间都可以被内核直接访问。所以在64位上，内核访问大于1G的内存地址，就不需要额外的步骤了，效率和性能上也大大增加，这也就是为什么要使用64位系统的原因。

在现在的PC架构上，AMD,INTER都支持一种机制，叫做PEA(物理地址扩展)。所谓PAE。指的是在32位系统的地址总线上，又扩展了4位，使得32位系统上的地址空间可以达到64G。当然在32为系统上，不管你的物理内存有多大，单个进程所使用的空间是无法扩展的。因为在32位的系统上，线性地址空间只有4个G，而单个进程能够识别的访问也只有3个G。

linux的虚拟内存子系统包含了以下几个功能模块：

slab allocator,zoned buddy allocator,MMU,kswapd,bdflush

slab allocator叫做slab分配器

buddy allocator又叫做buddy system，叫做伙伴系统，也是一种内存分配器

buddy system是工作在MMU之上的，而slab allocator又是工作在buddy system之上的。

设置为小于等于1G，在数据库服务器应该劲量避免使用交换内存

3.在应用服务器上，可以设置为RAM*0.5，当然这个是理论值

如果不的不使用交换内存，应该把交换内存放到最靠外的磁道分区上，因为最外边的磁盘的访问速度最快。所以如果有多块硬盘，可以把每块硬盘的最外层的磁道拿一小部分出来作为交换分区。交换分区可以定义优先级，因此把这些硬盘的交换内存的优先级设置为一样，可以实现负载均衡的效果。定义交换分区优先级的方法为编辑/etc/fstab：

/dev/sda1 swap swap pri=5 0 0

/dev/sdb1 swap swap pri=5 0 0

/dev/sdc1 swap swap pri=5 0 0

/dev/sdd1 swap swap pri=5 0 0

四.内存耗尽时候的相关调优参数

当Linux内存耗尽的时候，它会杀死那些占用内存最多的进程，以下三种情况会杀死进程：

1.所有的进程都是活动进程，这个时候想交换出去都没有空闲的进程

2.没有可用的page页在ZONE_NORMAL中

3.有其它新进程启动，申请内存空间的时候，要找一个空闲内存给做映射，但是这个时候找不到了

一旦内存耗尽的时候，操作系统就会启用oom-kill机制。

在/proc/PID/目录下有一个文件叫做oom_score,就是用来指定oom的评分的，就是坏蛋指数。

如果要手动启用oom-kill机制的话，只需要执行echo f>/proc/sysrq-trigger即可，它会自动杀掉我们指定的坏蛋指数评分最高的那个进程

可以通过echo n > /proc/PID/oom_adj来调整一个进程的坏蛋评分指数。最终的评分指数就是2的oom_adj的值的N次方。假如我们的一个进程的oom_adj的值是5，那么它的坏蛋评分指数就是2的5次方。

如果想禁止oom-kill功能的使用可以使用vm.panic_on_oom=1即可。

五.与容量有关的内存调优参数：

overcommit_memory,可用参数有3个，规定是否能够过量使用内存：

0：默认设置，内核执行启发式的过量使用处理

1：内核执行无内存的过量使用处理。使用这个值会增大内存超载的可能性

2：内存的使用量等于swap的大小+RAM*overcommit_ratio的值。如果希望减小内存的过度使用，这个值是最安全的

overcommit_ratio:将overcommit_memory指定为2时候，提供的物理RAM比例，默认为50

六.与通信相关的调优参数

常见在同一个主机中进行进程间通信的方式：

1.通过消息message;2.通过signal信号量进行通信;3.通过共享内存进行通信，跨主机常见的通信方式是rpc

以消息的方式实现进程通信的调优方案：

msgmax:以字节为单位规定消息队列中任意消息的最大允许大小。这个值一定不能超过该队列的大小(msgmnb)，默认值为65536

msgmnb:以字节为单位规定单一消息队列的最大值(最大长度)。默认为65536字节

msgmni:规定消息队列识别符的最大数量(及队列的最大数量)。64位架构机器的默认值为1985;32位架构机器的默认值为1736

以共享内存方式实现进程通信的调优方案：

shmall:以字节为单位规定一次在该系统中可以使用的共享内存总量(单次申请的上限)

shmmax:以字节为单位规定每一个共享内存片段的最大大小

shmmni:规定系统范围内最大共享内存片段。在64和32位的系统上默认值都是4096

七.与容量相关的文件系统可调优参数：

file-max:列出内核分配的文件句柄的最大值

dirty_ratio:规定百分比值，当脏数据达到系统内存总数的这个百分比值后开始执行pdflush,默认为20

dirty_background_ratio:规定百分比值，当某一个进程自己所占用的脏页比例达到系统内存总数的这个百分比值后开始在后台执行pdflush，默认为10

dirty_expire_centisecs:pdlush每隔百分之一秒的时间开启起来刷新脏页，默认值为3000，所以每隔30秒起来开始刷新脏页

dirty_writeback_centisecs:每隔百分之一秒开始刷新单个脏页。默认值为500，所以一个脏页的存在时间达到了5秒，就开始刷新脏

八.linux内存常用的观察指标命令：

Memory activity

vmstat [interval] [count]

sar -r [interval] [count]

Rate of change in memory

sar -R [interval] [count]

frmpg/s:每秒释放或者分配的内存页，如果为正数，则为释放的内存页;如果为负数，则为分配的内存页

bufpg/s:每秒buffer中获得或者释放的内存页。如果为正数则为获得的内存页，为负数。则为释放的内存页

campg/s:每秒cache中获得或者释放的内存页。如果为正数则为获得的内存页，为负数。则为释放的内存页

Swap activity

sar -W [interval] [count]

ALL IO

sar -B [interval] [count]

pgpgin/s:每秒从磁盘写入到内核的块数量

pgpgout/s:每秒从内核写入到磁盘的块数量

fault/s:每秒钟出现的缺页异常的个数

majflt/s:每秒钟出现的大页异常的个数

pgfree/s:每秒回收回来的页面个数

Ⅳ Linux进程间通信

linux下进程间通信的几种主要手段简介：

一般文件的I/O函数都可以用于管道，如close、read、write等等。

实例1：用于shell

管道可用于输入输出重定向，它将一个命令的输出直接定向到另一个命令的输入。比如，当在某个shell程序（Bourne shell或C shell等）键入who│wc -l后，相应shell程序将创建who以及wc两个进程和这两个进程间的管道。

实例二：用于具有亲缘关系的进程间通信

管道的主要局限性正体现在它的特点上：

有名管道的创建

小结：

管道常用于两个方面：（1）在shell中时常会用到管道（作为输入输入的重定向），在这种应用方式下，管道的创建对于用户来说是透明的；（2）用于具有亲缘关系的进程间通信，用户自己创建管道，并完成读写操作。

FIFO可以说是管道的推广，克服了管道无名字的限制，使得无亲缘关系的进程同样可以采用先进先出的通信机制进行通信。

管道和FIFO的数据是字节流，应用程序之间必须事先确定特定的传输"协议"，采用传播具有特定意义的消息。

要灵活应用管道及FIFO，理解它们的读写规则是关键。

信号生命周期

信号是进程间通信机制中唯一的异步通信机制，可以看作是异步通知，通知接收信号的进程有哪些事情发生了。信号机制经过POSIX实时扩展后，功能更加强大，除了基本通知功能外，还可以传递附加信息。

可以从两个不同的分类角度对信号进行分类：（1）可靠性方面：可靠信号与不可靠信号；（2）与时间的关系上：实时信号与非实时信号。

(1) 可靠信号与不可靠信号

不可靠信号 ：Linux下的不可靠信号问题主要指的是信号可能丢失。

可靠信号 ：信号值位于SIGRTMIN和SIGRTMAX之间的信号都是可靠信号，可靠信号克服了信号可能丢失的问题。Linux在支持新版本的信号安装函数sigation（）以及信号发送函数sigqueue()的同时，仍然支持早期的signal（）信号安装函数，支持信号发送函数kill()。

对于目前linux的两个信号安装函数:signal()及sigaction()来说，它们都不能把SIGRTMIN以前的信号变成可靠信号（都不支持排队，仍有可能丢失，仍然是不可靠信号），而且对SIGRTMIN以后的信号都支持排队。这两个函数的最大区别在于，经过sigaction安装的信号都能传递信息给信号处理函数（对所有信号这一点都成立），而经过signal安装的信号却不能向信号处理函数传递信息。对于信号发送函数来说也是一样的。

(2) 实时信号与非实时信号

前32种信号已经有了预定义值，每个信号有了确定的用途及含义，并且每种信号都有各自的缺省动作。如按键盘的CTRL ^C时，会产生SIGINT信号，对该信号的默认反应就是进程终止。后32个信号表示实时信号，等同于前面阐述的可靠信号。这保证了发送的多个实时信号都被接收。实时信号是POSIX标准的一部分，可用于应用进程。非实时信号都不支持排队，都是不可靠信号；实时信号都支持排队，都是可靠信号。

发送信号的主要函数有：kill()、raise()、 sigqueue()、alarm()、setitimer()以及abort()。

调用成功返回 0；否则，返回 -1。

sigqueue()是比较新的发送信号系统调用，主要是针对实时信号提出的（当然也支持前32种），支持信号带有参数，与函数sigaction()配合使用。

sigqueue的第一个参数是指定接收信号的进程ID，第二个参数确定即将发送的信号，第三个参数是一个联合数据结构union sigval，指定了信号传递的参数，即通常所说的4字节值。

sigqueue()比kill()传递了更多的附加信息，但sigqueue()只能向一个进程发送信号。sigqueue()比kill()传递了更多的附加信息，但sigqueue()只能向一个进程发送信号。

inux主要有两个函数实现信号的安装： signal() 、 sigaction() 。其中signal()在可靠信号系统调用的基础上实现, 是库函数。它只有两个参数，不支持信号传递信息，主要是用于前32种非实时信号的安装；而sigaction()是较新的函数（由两个系统调用实现：sys_signal以及sys_rt_sigaction），有三个参数，支持信号传递信息，主要用来与 sigqueue() 系统调用配合使用，当然，sigaction()同样支持非实时信号的安装。sigaction()优于signal()主要体现在支持信号带有参数。

消息队列就是一个消息的链表。可以把消息看作一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息。消息队列是随内核持续的

消息队列的内核持续性要求每个消息队列都在系统范围内对应唯一的键值，所以，要获得一个消息队列的描述字，只需提供该消息队列的键值即可；

消息队列与管道以及有名管道相比，具有更大的灵活性，首先，它提供有格式字节流，有利于减少开发人员的工作量；其次，消息具有类型，在实际应用中，可作为优先级使用。这两点是管道以及有名管道所不能比的。同样，消息队列可以在几个进程间复用，而不管这几个进程是否具有亲缘关系，这一点与有名管道很相似；但消息队列是随内核持续的，与有名管道（随进程持续）相比，生命力更强，应用空间更大。

信号灯与其他进程间通信方式不大相同，它主要提供对进程间共享资源访问控制机制。相当于内存中的标志，进程可以根据它判定是否能够访问某些共享资源，同时，进程也可以修改该标志。除了用于访问控制外，还可用于进程同步。信号灯有以下两种类型：

int semop(int semid, struct sembuf *sops, unsigned nsops); semid是信号灯集ID，sops指向数组的每一个sembuf结构都刻画一个在特定信号灯上的操作。

int semctl(int semid，int semnum，int cmd，union semun arg)
该系统调用实现对信号灯的各种控制操作，参数semid指定信号灯集，参数cmd指定具体的操作类型；参数semnum指定对哪个信号灯操作，只对几个特殊的cmd操作有意义；arg用于设置或返回信号灯信息。

进程间需要共享的数据被放在一个叫做IPC共享内存区域的地方，所有需要访问该共享区域的进程都要把该共享区域映射到本进程的地址空间中去。系统V共享内存通过shmget获得或创建一个IPC共享内存区域，并返回相应的标识符。内核在保证shmget获得或创建一个共享内存区，初始化该共享内存区相应的shmid_kernel结构注同时，还将在特殊文件系统shm中，创建并打开一个同名文件，并在内存中建立起该文件的相应dentry及inode结构，新打开的文件不属于任何一个进程（任何进程都可以访问该共享内存区）。所有这一切都是系统调用shmget完成的。

shmget（）用来获得共享内存区域的ID，如果不存在指定的共享区域就创建相应的区域。shmat()把共享内存区域映射到调用进程的地址空间中去，这样，进程就可以方便地对共享区域进行访问操作。shmdt()调用用来解除进程对共享内存区域的映射。shmctl实现对共享内存区域的控制操作。这里我们不对这些系统调用作具体的介绍，读者可参考相应的手册页面，后面的范例中将给出它们的调用方法。

注：shmget的内部实现包含了许多重要的系统V共享内存机制；shmat在把共享内存区域映射到进程空间时，并不真正改变进程的页表。当进程第一次访问内存映射区域访问时，会因为没有物理页表的分配而导致一个缺页异常，然后内核再根据相应的存储管理机制为共享内存映射区域分配相应的页表。