Linux内存机制（swap）

我们知道，直接从物理内存读写数据要比从硬盘读写数据要快的多，因此，我们希望所有数据的读取和写入都在内存完成，而内存是有限的，这样就引出了物理内存与虚拟内存的概念。

物理内存就是系统硬件提供的内存大小，是真正的内存，相对于物理内存，在linux下还有一个虚拟内存的概念，虚拟内存就是为了满足物理内存的不足而提出的策略，它是利用磁盘空间虚拟出的一块逻辑内存，用作虚拟内存的磁盘空间被称为交换空间（Swap Space）。

作为物理内存的扩展，linux会在物理内存不足时，使用交换分区的虚拟内存，更详细的说，就是内核会将暂时不用的内存块信息写到交换空间，这样以来，物理内存得到了释放，这块内存就可以用于其它目的，当需要用到原始的内容时，这些信息会被重新从交换空间读入物理内存。

Linux的内存管理采取的是分页存取机制，为了保证物理内存能得到充分的利用，内核会在适当的时候将物理内存中不经常使用的数据块自动交换到虚拟内存中，而将经常使用的信息保留到物理内存。

要深入了解linux内存运行机制，需要知道下面提到的几个方面：

Linux系统会不时的进行页面交换 *** 作，以保持尽可能多的空闲物理内存，即使并没有什么事情需要内存，Linux也会交换出暂时不用的内存页面。这可以避免等待交换所需的时间。

Linux 进行页面交换是有条件的，不是所有页面在不用时都交换到虚拟内存，linux内核根据”最近最经常使用“算法，仅仅将一些不经常使用的页面文件交换到虚拟 内存，有时我们会看到这么一个现象：linux物理内存还有很多，但是交换空间也使用了很多。其实，这并不奇怪，例如，一个占用很大内存的进程运行时，需 要耗费很多内存资源，此时就会有一些不常用页面文件被交换到虚拟内存中，但后来这个占用很多内存资源的进程结束并释放了很多内存时，刚才被交换出去的页面 文件并不会自动的交换进物理内存，除非有这个必要，那么此刻系统物理内存就会空闲很多，同时交换空间也在被使用，就出现了刚才所说的现象了。关于这点，不 用担心什么，只要知道是怎么一回事就可以了。

交换空间的页面在使用时会首先被交换到物理内存，如果此时没有足够的物理内存来容纳这些页 面，它们又会被马上交换出去，如此以来，虚拟内存中可能没有足够空间来存储这些交换页面，最终会导致linux出现假死机、服务异常等问题，linux虽 然可以在一段时间内自行恢复，但是恢复后的系统已经基本不可用了。

因此，合理规划和设计Linux内存的使用，是非常重要的.

在Linux *** 作系统中，当应用程序需要读取文件中的数据时， *** 作系统先分配一些内存，将数据从磁盘读入到这些内存中，然后再将数据分发给应用程序；当需要往文件中写 数据时， *** 作系统先分配内存接收用户数据，然后再将数据从内存写到磁盘上。然而，如果有大量数据需要从磁盘读取到内存或者由内存写入磁盘时，系统的读写性 能就变得非常低下，因为无论是从磁盘读数据，还是写数据到磁盘，都是一个很消耗时间和资源的过程，在这种情况下，Linux引入了buffers和 cached机制。

buffers与cached都是内存 *** 作，用来保存系统曾经打开过的文件以及文件属性信息，这样当 *** 作系统需要读取某些文件时，会首先在buffers 与cached内存区查找，如果找到，直接读出传送给应用程序，如果没有找到需要数据，才从磁盘读取，这就是 *** 作系统的缓存机制，通过缓存，大大提高了 *** 作系统的性能。但buffers与cached缓冲的内容却是不同的。

buffers是用来缓冲块设备做的，它只记录文件系统的元数据（metadata）以及 tracking in-flight pages，而cached是用来给文件做缓冲。更通俗一点说：buffers主要用来存放目录里面有什么内容，文件的属性以及权限等等。而cached直接用来记忆我们打开过的文件和程序。

为了验证我们的结论是否正确，可以通过vi打开一个非常大的文件，看看cached的变化，然后再次vi这个文件，感觉一下两次打开的速度有何异同，是不是第二次打开的速度明显快于第一次呢？接着执行下面的命令：

find / -name .conf 看看buffers的值是否变化，然后重复执行find命令，看看两次显示速度有何不同。

上面这个60代表物理内存在使用40%的时候才会使用swap（参考网络资料：当剩余物理内存低于40%（40=100-60）时，开始使用交换空间） swappiness=0的时候表示最大限度使用物理内存，然后才是 swap空间，swappiness＝100的时候表示积极的使用swap分区，并且把内存上的数据及时的搬运到swap空间里面。

值越大表示越倾向于使用swap。可以设为0，这样做并不会禁止对swap的使用，只是最大限度地降低了使用swap的可能性。

通常情况下：swap分区设置建议是内存的两倍 （内存小于等于4G时），如果内存大于4G，swap只要比内存大就行。另外尽量的将swappiness调低，这样系统的性能会更好。

B. 修改swappiness参数

永久性修改：

立即生效，重启也可以生效。

一般系统是不会自动释放内存的 关键的配置文件/proc/sys/vm/drop_caches。这个文件中记录了缓存释放的参数，默认值为0，也就是不释放缓存。他的值可以为0~3之间的任意数字，代表着不同的含义：

0 – 不释放 1 – 释放页缓存 2 – 释放dentries和inodes 3 – 释放所有缓存

前提：首先要保证内存剩余要大于等于swap使用量，否则会宕机！根据内存机制，swap分区一旦释放，所有存放在swap分区的文件都会转存到物理内存上。通常通过重新挂载swap分区完成释放swap。

a.查看当前swap分区挂载在哪？b.关停这个分区 c.查看状态：d.查看swap分区是否关停，最下面一行显示全 e.将swap挂载到/dev/sda5上 f.查看挂载是否成功

Linux内核中的RCU机制

RCU的设计思想比较明确，通过新老指针替换的方式来实现免锁方式的共享保护。但是具体到代码的层面，理解起来多少还是会有些困难。下面我准备了关于Linux内核中的RCU机制的文章，提供给大家参考!

RCU读取侧进入临界区的标志是调用rcu_read_lock，这个函数的代码是：

static inline void rcu_read_lock(void)

{

__rcu_read_lock()

__acquire(RCU)

rcu_read_acquire()

}

该实现里面貌似有三个函数调用，但实质性的工作由第一个函数__rcu_read_lock()来完成，__rcu_read_lock()通过调用 preempt_disable()关闭内核可抢占性。但是中断是允许的，假设读取者正处于rcu临界区中且刚读取了一个共享数据区的指针p(但是还没有访问p中的数据成员)，发生了一个中断，而该中断处理例程ISR恰好需要修改p所指向的数据区，按照RCU的设计原则，ISR会新分配一个同样大小的数据区new_p，再把老数据区p中的数据拷贝到新数据区，接着是在new_p的基础上做数据修改的工作(因为是在new_p空间中修改，所以不存在对p的并发访问，因此说RCU是一种免锁机制，原因就在这里)，ISR在把数据更新的工作完成后，将new_p赋值给p(p=new_p),最后它会再注册一个回调函数用以在适当的时候释放老指针p。因此，只要对老指针p上的所有引用都结束了，释放p就不会有问题。当中断处理例程做完这些工作返回后，被中断的进程将依然访问到p空间上的数据，也就是老数据，这样的结果是RCU机制所允许的。RCU规则对读取者与写入者之间因指针切换所造成的短暂的资源视图不一致问题是允许的。

接下来关于RCU一个有趣的问题是：何时才能释放老指针。我见过很多书中对此的'回答是：当系统中所有处理器上都发生了一次进程切换。这种程式化的回答常常让刚接触RCU机制的读者感到一头雾水，为什么非要等所有处理器上都发生一次进程切换才可以调用回调函数释放老指针呢?这其实是RCU的设计规则决定的： 所有对老指针的引用只可能发生在rcu_read_lock与rcu_read_unlock所包括的临界区中，而在这个临界区中不可能发生进程切换，而一旦出了该临界区就不应该再有任何形式的对老指针p的引用。很明显，这个规则要求读取者在临界区中不能发生进程切换，因为一旦有进程切换，释放老指针的回调函数就有可能被调用，从而导致老指针被释放掉，当被切换掉的进程被重新调度运行时它就有可能引用到一个被释放掉的内存空间。

现在我们看到为什么rcu_read_lock只需要关闭内核可抢占性就可以了，因为它使得即便在临界区中发生了中断，当前进程也不可能被切换除去。 内核开发者，确切地说，RCU的设计者所能做的只能到这个程度。接下来就是使用者的责任了，如果在rcu的临界区中调用了一个函数，该函数可能睡眠，那么RCU的设计规则就遭到了破坏，系统将进入一种不稳定的状态。

这再次说明，如果想使用一个东西，一定要搞清楚其内在的机制，象上面刚提到的那个例子，即便现在程序不出现问题，但是系统中留下的隐患如同一个定时炸d， 随时可能被引爆，尤其是过了很长时间问题才突然爆发出来。绝大多数情形下，找到问题所花费的时间可能要远远大于静下心来仔细搞懂RCU的原理要多得多。

RCU中的读取者相对rwlock的读取者而言，自由度更高。因为RCU的读取者在访问一个共享资源时，不需要考虑写入者的感受，这不同于rwlock的写入者，rwlock reader在读取共享资源时需要确保没有写入者在 *** 作该资源。两者之间的差异化源自RCU对共享资源在读取者与写入者之间进行了分离，而rwlock的 读取者和写入者则至始至终只使用共享资源的一份拷贝。这也意味着RCU中的写入者要承担更多的责任，而且对同一共享资源进行更新的多个写入者之间必须引入某种互斥机制，所以RCU属于一种"免锁机制"的说法仅限于读取者与写入者之间。所以我们看到：RCU机制应该用在有大量的读取 *** 作，而更新 *** 作相对较少的情形下。此时RCU可以大大提升系统系能，因为RCU的读取 *** 作相对其他一些有锁机制而言，在锁上的开销几乎没有。

实际使用中，共享的资源常常以链表的形式存在，内核为RCU模式下的链表 *** 作实现了几个接口函数，读取者和使用者应该使用这些内核函数，比如 list_add_tail_rcu, list_add_rcu，hlist_replace_rcu等等，具体的使用可以参考某些内核编程或者设备驱动程序方面的资料。

在释放老指针方面，Linux内核提供两种方法供使用者使用，一个是调用call_rcu,另一个是调用synchronize_rcu。前者是一种异步 方式，call_rcu会将释放老指针的回调函数放入一个结点中，然后将该结点加入到当前正在运行call_rcu的处理器的本地链表中，在时钟中断的 softirq部分(RCU_SOFTIRQ)， rcu软中断处理函数rcu_process_callbacks会检查当前处理器是否经历了一个休眠期(quiescent，此处涉及内核进程调度等方面的内容)，rcu的内核代码实现在确定系统中所有的处理器都经历过了一个休眠期之后(意味着所有处理器上都发生了一次进程切换，因此老指针此时可以被安全释放掉了)，将调用call_rcu提供的回调函数。

synchronize_rcu的实现则利用了等待队列，在它的实现过程中也会向call_rcu那样向当前处理器的本地链表中加入一个结点，与 call_rcu不同之处在于该结点中的回调函数是wakeme_after_rcu，然后synchronize_rcu将在一个等待队列中睡眠，直到系统中所有处理器都发生了一次进程切换，因而wakeme_after_rcu被rcu_process_callbacks所调用以唤醒睡眠的 synchronize_rcu，被唤醒之后，synchronize_rcu知道它现在可以释放老指针了。

所以我们看到，call_rcu返回后其注册的回调函数可能还没被调用，因而也就意味着老指针还未被释放，而synchronize_rcu返回后老指针肯定被释放了。所以，是调用call_rcu还是synchronize_rcu，要视特定需求与当前上下文而定，比如中断处理的上下文肯定不能使用 synchronize_rcu函数了。

　进程提供了两种优先级，一种是普通的进程优先级，第二个是实时优先级。前者适用SCHED_NORMAL调度策略，后者可选SCHED_FIFO或SCHED_RR调度策略。任何时候，实时进程的优先级都高于普通进程，实时进程只会被更高级的实时进程抢占，同级实时进程之间是按照FIFO（一次机会做完）或者RR（多次轮转）规则调度的。

首先，说下实时进程的调度

实时进程，只有静态优先级，因为内核不会再根据休眠等因素对其静态优先级做调整，其范围在0~MAX_RT_PRIO-1间。默认MAX_RT_PRIO配置为100，也即，默认的实时优先级范围是0~99。而nice值，影响的是优先级在MAX_RT_PRIO~MAX_RT_PRIO+40范围内的进程。

---