对于网站建设的体会,设计之家室内设计,wordpress分享点赞,wordpress ppt演示一、前言每一个Linux驱动工程师都知道这样一个准则#xff1a;在中断上下文中不能睡眠。但是为什么interrupt context中不能调用导致睡眠的kernel API呢#xff1f;如果驱动这么做会导致什么样的后果呢#xff1f;这就是本文探讨的主题。为了理解这个主题#xff0c;我们设…一、前言每一个Linux驱动工程师都知道这样一个准则在中断上下文中不能睡眠。但是为什么interrupt context中不能调用导致睡眠的kernel API呢如果驱动这么做会导致什么样的后果呢这就是本文探讨的主题。为了理解这个主题我们设计了一些非常简单的驱动程序和用户空间的程序实际做实验观察实验效果最后给出了结果和分析。BTW本文的实验在X86 64bit 标准4.4内核上完成。二、测试程序1、cst驱动模块我们首先准备一个能够在中断上下文中睡眠的驱动程序在这里我称之Context schedule test module(后文简称cst模块)。这个驱动程序类似潜伏在内核中的“捣蛋鬼”每隔1秒随机命中一个进程然后引发调度。首先准备一个Makefile代码如下按理说代码中的xxxx应该是我的名字如果你愿意在你的环境中测试可以修改成你的名字当然最重要的是需要某个版本的内核代码。在内核升级文档中我已经编译了/home/xxxx/work/linux-4.4.6目录下的内核并把我的计算机升级到4.4.6的内核上如果你愿意可以按照那份文档进行升级否则可能会有一些版本问题需要处理。除了Makefile之外还需要一个Kbuild文件obj-m : cst.o当然最重要的是cst模块的源代码代码非常的简单无需多说直接make就可以编译得到cst.ko的内核模块了。2、用户空间测试程序为了更方便的测试我们需要准备一个“受害者”代码如下这段代码也很简单不断的产生一个随机数并运算其平方根在使得的时候向用户输出一些字符表明自己的状态。当程序执行起来的时候大部分时间在用户态(运算)偶尔进入内核态(printf)。这个进程并不知道在内核态有一个cst的模块每隔一秒就发射一只休眠之箭可能命中用户态也可能命中内核态看运气吧但是无论怎样该进程被射中之后都会进入睡眠。三、执行测试并观察结果1、先把用户空间的测试程序跑起来要想测试导弹(呵呵我们的cst模块就是一个捣蛋) 的性能必须要有靶机或者靶舰。当然也可以不用“靶机”程序只不过捣蛋鬼cst总是命中swapper进程有点无趣因此这里需要把我们用户空间的那个测试程序跑起来让CPU先活跃起来。需要注意的是在多核cpu上我们需要多跑几个“靶机”进程才能让系统不会always进入idle状态。例如我的T450是4核cpu因此我需要运行4个靶机程序才能让系统中的4个cpu core都燥起来。可以通过下面的命令确认ps –eo comm,psr | grep cstBTW靶机程序是cst_test。通过上面的命令可以看到系统中运行了四个cst_test进程分别在4个cpu上。2、插入内核模块靶机已经就绪是时候发射捣蛋了命令如下sudo insmod ./cst.ko一旦插入了cst内核模块捣蛋鬼就开始运作了每隔1秒钟发射一次总有一个倒霉蛋被命中被调度。当然在我们的测试中一般总是cst_test这个进程被命中。3、观察结果一切准备就绪是时候搬个小板凳坐下来看好戏了。当然我们需要一个观察的工具输入如下命令sudo tail –f /var/log/messages在上面的cst模块中输出并没有直接到控制台因此我们需要通过内核日志来看看cst的运行情况。四、结果和分析1、结果很奇怪一切都是正常的系统没有死cst模块也运行正常cst_test进程也始终保持alive状态不断的运行在无聊的平方根、打印着无聊的字符串。唯一异常的是日志每隔1秒钟就会dump stack一次。2、分析当cst模块命中cst_test进程无论是userspace还是kernel space都会在内核栈上保存中断发生那一点的上下文唯一不同是如果发生在userspace那么发生中断那一刻内核栈是空的而如果在kernel space内核栈上已经有了cst_test通过系统调用进入内核的现场以及该系统调用各个函数的stack frame当中断发生的时候在当前内核栈的栈顶上继续压入了中断现场之后就是中断处理的各个函数的stack frame最后是cst_timer_handler的stack frame由于调用了schedule函数cst_test进程的现场被继续压入内核栈调度器决定下一个调度的进程。cst_test进程虽然被调度了但是仍然在runqueue中调度器一定会在适当的时机调度cst_test进程重新进入执行态这时候恢复其执行就OK了cpu执行cst_TImer_handler函数schedule之后的代码继续未完的中断上下文的执行然后从内核栈恢复中断现场一切又按照原路返回了。当然这里的测试看起来一切OK但这并不是说可以自由的在中断上下文中调用导致睡眠的内核API因为我们这里给出了一个简单的例子实际上也有可能导致系统死锁。例如在内核态持有锁的时候被中断然后发生调度。有兴趣的同学可以自己修改上面的代码实验这种情况。3、why最后还是回到这个具体的技术问题为什么interrupt context中不能调用导致睡眠的kernel API我的看法是这样的调度器是每一个OS的必备组件在编码阶段之前我们往往要制定下我们的设计概念。对于Linux 调度器它的目标就是调度一个线程一个线程就是调度实体(暂不考虑group sched)。中断上下文是不是调度实体呢当然不是它没有专属的task struct内核无从调度。这是调度器设计者的决定这样的决定让调度器设计起来简洁而美丽。基于上面的设计概念中断上下文(hard irq和sofTIrq context)并不参与调度(暂不考虑中断线程化)它们是异步事件的处理机制目标就是尽快完成处理返回现场。因此所有中断上下文的优先级都是高于进程上下文的也就是说对于用户进程(无论内核态还是用户态)或者内核线程除非disable了CPU的本地中断否则一旦中断发生它们是没有任何能力阻挡中断上下文抢占当前进程上下文的执行的。因此Linux kernel的设计者制定了规则1、中断上下文不是调度实体2、中断上下文的优先级高于进程上下文而在中断上下文中调度毫无疑问会打破规则因此不能在硬中断、软中断环境中调用阻塞函数。不过在linux调度器的具体实现的时候检测到了在中断上下文中调度schedule函数也并没有强制linux进入panic可能是linux的开发者认为一个好的内核调度器无论如何也尽自己最大的努力让系统运行下去吧。但是在厂商自己提供的内核中往往修改调度器行为在中断上下文中检测到调度就直接panic了对于内核开发者而言这样更好可以尽早的发现问题。