软中断

谈论进程上下文 、中断上下文 、 原子上下文之前，有必要讨论下两个概念： a -- 上下文 上下文是从英文 contex t翻译过来，指的是一种 环境 。相对于进程而言，就是进程执行时的环境； 具体来说就是各个变量和数据，包括所有的寄存器变量、进程打开的文件、内存信息等。 b -- 原子 原子（atom） 本意是“不能被进一步分割的最小粒子”，而 原子操作（atomic operation ）意为"不可被中断的一个或一系列操作" ； 一、为什么会有上下文这种概念 内核空间和用户空间是现代 操作系统 的两种工作模式，内核模块运行在内核空间，而用户态应用程序运行在用户空间。它们代表不同的级别，而对系统资源具有不同的访问权限。内核模块运行在最高级别（内核态），这个级下所有的操作都受系统信任，而应用程序运行在较低级别（用户态）。在这个级别，处理器控制着对硬件的直接访问以及对内存的非授权访问。内核态和用户态有自己的内存映射，即自己的地址空间。 其中处理器总处于以下状态中的一种： 内核态 ，运行于 进程上下文 ，内核代表进程运行于内核空间； 内核态 ，运行于 中断上下文 ，内核代表硬件运行于内核空间； 用户态 ，运行于用户空间。 　　上下文的切换，用户空间和内核空间具有不同的 地址映射，通用或专用的寄存器组，而用户空间的进程要传递很多变量、参数给内核，内核也要保存用户进程的一些寄存器、变量等

在linux 3.10环境一次故障处理中，发现有类似如下打印： NFO: rcu_sched_state detected stalls on CPUs/tasks: {15 } (detected by 4, 6002 jiffies,其余信息省略) 该环境没有开启rcu的callback线程，也就是rcu是在软中断中处理。 获取信息发现，有一个核的rcu的qlen已经达到了几百万，而且维持不变，也就是，既没有新的rcu挂在这个核，也没见这个核处理rcu。 查看对应的percpu的softirq统计，发现没有rcu的软中断触发。 由于线上环境不能久等，担心因为rcu的释放积压导致出现oom，所以干脆使用如下方式来解决： 1.要么写一个模块触发一下软中断，因为当时看这个核是idle的，也没有关中断，这种方式应该可行。 2.简单方法，利用cpu的热插拔特性，将这个核下线，然后再上线，果然rcu的qlen减少到0了。 来源： https://www.cnblogs.com/10087622blog/p/11688661.html

CPU性能指标       （1）CPU使用率 ：1） 用户态CPU使用率（包括用户态 user 和低优先级用户态 nice）、2） 系统CPU使用率、3） 等待 I/O 的CPU使用率、4） 软中断和硬中断的CPU使用率、5） 虚拟机占用的CPU使用率。    （2）平均负载 Load Average ：过去 1 分钟、过去 5 分钟和过去 15 分钟的平均负载    （3）进程上下文切换 ：1） 无法获取资源而导致的自愿上下文切换；2） 被系统强制调度导致的非自愿上下文切换。    （4）CPU缓存命中率 ：因为CPU处理速度比内存访问速度快得多，则需要等待内存的响应。为了协调两者性能差距，出现了CPU的多级缓存。如下图所示，L1、L2属于单核，L3用在多核中，缓存大小依次增大、性能依次降低。缓存命中率，衡量的是CPU缓存的复用情况，命中率越高、复用越多，性能越好。       性能工具    （1）平均负载案例 ： 1） uptime 查看了系统的平均负载，2） mpstat 和 pidstat 分别观察了每个 CPU 和每个进程 CPU 的使用情况。    （2）上下文切换的案例 ：1）vmstat 查看系统的上下文切换次数和中断次数；2）pidstat 观察进程的自愿上下文切换和非自愿上下文切换情况；3）pidstat 观察线程的上下文切换情况。    （3

  软中断（softirq）会导致CPU 使用率升高    中断 是系统用来响应硬件设备请求的一种机制，它会打断进程的正常调度和执行，然后调用内核中的中断处理程序来响应设备的请求。中断其实是一种异步的事件处理机制，可以提高系统的并发处理能力。由于中断处理程序会打断其他进程的运行，所以，为了减少对正常进程运行调度的影响，中断处理程序就需要尽可能快地运行。并且当CPU执行在中断处理函数中时，不会响应同时发生的又一次中断。   所以为了加快中断处理程序执行和解决中断丢失的问题，Linux将中断分为上半部和下半部。    上半部 ， 硬中断 ，用来 快速处理 中断，它在中断禁止模式下运行，主要处理跟硬件紧密相关的或时间敏感的工作，会打断 CPU 正在执行的任务。    下半部 ， 软中断 ，用来 延迟处理 上半部未完成的工作，通常由内核触发，以内核线程的方式运行。并且每个 CPU 都对应一个软中断内核线程，名字为 “ksoftirqd/ ” 。软中断不仅包括硬件处理程序的下半部，还包括一些内核自定义的事件，比如内核调度、RCU 锁（Read-Copy Update）、网络收发、定时等。   如：网卡接收数据的过程。对上半部来说，是把网卡的数据读到内存中，然后更新一下硬件寄存器的状态，再发送一个软中断信号，下半部就从内存中找到网络数据，再按照网络协议栈，对数据进行逐层解析和处理

转载： https://blog.csdn.net/kklvsports/article/details/74452953 收包流程： 传统方式和NAPI方式收包流程是有差异的，如图所示。 传统收包是中断，驱动处理完后直接调用netif_rx将报文送入内核处理，内核将报文skb挂到该CPU的softnet_data结构input_pkt_queue队列上， 为了统一传统收包和NAPI设备收包的处理，内核为所有不使用NAPI的驱动程序提供一个虚拟设备，叫做积压设备，每个CPU一个积压设备，对应结构softnet_data->backlog_dev。input_pkt_queue即是该设备的积压队列，用于存储skb，该队列是一个双向链表，组织结构如下。中断上半部只是将报文入队，并将backlog的实例挂到poll_list上，等待下半部软中断轮询poll_list net_rx_action->preocess_backlog将报文进一步处理。 input_pkt_queue structure +------------------------------------------------------------+ | | | skb_buff_head skb_buff skb_buff | | _______ _______________ _______________ |

1，为啥需要自旋锁 很多时候我们并不能采用其他的锁，比如读写锁、互斥锁、信号量等。一方面这些锁会发生上下文切换，他的时间是不可预期的，对于一些简单的、极短的临界区完全是一种性能损耗；另一方面在中断上下文是不允许睡眠的，除了自旋锁以外的其他任何形式的锁都有可能导致睡眠或者进程切换，这是违背了中断的设计初衷，会发生不可预知的错误。基于两点，我们需要自旋锁，他是不可替代的。 2，为啥自旋锁禁止抢占 这一点其实很好理解，当一个 CPU 获取到一把自旋锁之后，开始执行临界区代码，此时假设他的时间片运转完毕，进程调度会主动触发调度将其调走，执行另一个线程/进程，结果恰巧了这个线程/进程也需要用到该自旋锁，而上一个线程/进程还在停留在临界区内未释放锁，导致本进程无法获取到锁而形成死锁，所以自旋锁为了规避此类情形的出现从而直接禁止对已经开始运行的临界区设置禁止抢占标志。 3，为什么临界区禁止睡眠 如果自旋锁锁住以后进入睡眠，而此时又不能进行处理器抢占，内核的调取器无法调取其他进程获得该 CPU，从而导致该 CPU 被挂起；同时该进程也无法自唤醒且一直持有该自旋锁，进一步会导致其他使用该自旋锁的位置出现死锁。 4，spin_lock 系列的分别 每一种锁出现都有自己的原因，spin_lock 系列的锁就是为了解决这一个又一个的问题才会新增的各种自旋锁变种，这也符合现代计算机代码设计逻辑

如何让程序在后台运行 在之前的章节中，如果要运行程序，在命令提示行下输入程序名后回车，程序被执行，然后等待程序运行完成。在程序运行的过程中，可以用 Ctrl+c 中止它。 在实际开发中，我们需要让程序在后台运行，不受界面的影响，也不让程序员等待，例如前几章节的socket服务端程序。 如果想让程序在后台运行，有两种方法。 1、加“&”符号 如果想让程序在后台运行，执行程序的时候，命令的最后面加“&”符号。 如： ./book242 & 程序就在后台运行了。 在后台运行的程序，用Ctrl+c无法中断，并且就算终端退出了，程序仍在后台运行。 如果终端退出了，后台运行的程序将由系统托管。 在第一张图中，book249的父进程是4555，第二张图中，book249的父进程是1。 2、采用fork 另一种方法是采用fork，主程序执行fork，生成一个子进程，然后父进程退出，留下子进程继续运行，子进程将由系统托管。 示例： 上图中，突出显示的就是新增的代码。 上图中，子进程的父进程是系统进程。 3、如何让中止后台程序 问题来了，程序在后台运行了，离开了终端控制，用Ctrl+c上也无法中止，那怎么让它停下来呢？暂时用一个笨方法：杀了它。 杀程序有两个方法： 1 ）killall 程序名 killall book249 2 ）先用“ps -ef|grep 程序名”找到程序的进程编号，然后用