Linux内核3.11的socket busy poll机制避免睡眠切换

Linux的网络协议栈非常独立,上下通过两个接口分别和用户态以及设备相连,也可以看作是北向和南向接口...北向通过socket接口,南向通过qdisc接口(你可以认为是上层的netdev queue,对于接收接口,NAPI的poll队列则是另一个例子),不管是socket还是qdisc,都是基于队列来管理的,也就是说,三个部分是独立的,socket只能看到读写队列,而看不到协议栈本身,socket在读一个数据的时候,它取的是队列里面的数据,至于说这个数据是谁放进去的,它并不知道,是不是协议栈放进去的,它也不必验证。
       socket隔离了用户进程和协议栈,RX/TX queue隔离了协议栈和设备驱动。
       这种隔离方式给编程和设计带来了简便,然而却不利于性能。
       Linux的RPS设计,旨在让一个CPU既处理数据包的协议栈接收流程(软中断内核线程上下文,或者任意上下文的软中断处理),又运行用户态处理该数据包的进程。我说这种设计有利也有弊,如果仅仅是旨在提高cache利用率,那么这种设计是对的,但是有没有想过别的情况,如果一个CPU在NET RX软中断处理的最后将一个skb推到了一个socket队列,并试图唤醒等待进程,那么它下一步该干些什么呢?实际上它下一步应该返回设备,继续去poll下一个skb,然而RPS的设计不是这样,RPS的设计旨在希望让该CPU继续处理用户态进程....这就必然要进行一次进程切换以及用户/内核态的切换,虽然服务器的CPU cache利用率提高了,但是协议栈处理相关的CPU cache利用率反而降低了。事实上,CPU cache是否在进程切换以及用户/内核态切换后刷新,这个是体系结构相关的,并不是说所有的体系结构都能带来好的结果。
       必须做进一步的测试。
       我觉得最好的办法就是用户进程和内核的NET RX软中断处在不同的CPU核心上,然而这两个CPU核心共享二级cache或者三级cache。
       ...
       Linux内核随之发展出了更好的方案,那就是突破上述的独立三大部分,让socket直接深入到设备层直接poll skb!!注意,这是一个poll操作,并不是让socket直接处理协议栈流程。socket直接poll的意思是说,socket在队列中没有读到数据包的时候,并不是睡眠,然后等待NET RX内核线程将数据包放入队列后将其唤醒,而是直接去问设备:现在有数据包吗?如果有,我直接带走它们去协议栈,而不需要你送它们去了。这是一种“拉”的方式,而不是以往的那种“推”的方式,拉和推的区别在于,对于接收者,拉是同一个实体,是主动的,而推则是被动的。
       这就解决了RPS试图解决却又没有完美解决的问题。这种机制叫做busy poll。
       RPS试图让软中断处理完数据包后,切换到用户进程,此时软中断将间歇,然后数据包中断后又要切回来...busy poll就不是这样,它直接绕过了软中断这个执行体,直接靠socket自身所在的执行体来主动拉取数据包进行处理。避免了大量的任务交接导致的切换问题。
       我不晓得对于转发的情况,是否也能采用busy poll的方式来提高性能,这需要测试。以上的阐述只是理想情况,真实情况是,socket可能替别的socket从设备拉取了一个数据包,甚至这个数据包只是转发的,不与任何socket关联...因为数据包只有经过标准的路由以及四层处理后,才能和一个具体socket关联,在设备驱动层,指望找到这个关联是徒劳且无望的!不管怎么说,控制权在用户自己手中,凭概率来讲,如果你的设备中大量的数据包都是转发包,就不要开启这个功能,如果你的进程拥有少量的socket处理大量的数据包,那就开启它,不管怎样,这只是一个用法和配置的问题,何时开启,以及份额设置多少,需要一个事前采样的过程。
       今天早上起太早,写了两篇随笔,所以也就没出去溜,现在快七点了,小小和孩她妈还睡着呢,我准备下去上班了....

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-10-06 15:42:53

Linux内核3.11的socket busy poll机制避免睡眠切换的相关文章

解析 Linux 内核可装载模块的版本检查机制

转自:http://www.ibm.com/developerworks/cn/linux/l-cn-kernelmodules/ 为保持 Linux 内核的稳定与可持续发展,内核在发展过程中引进了可装载模块这一特性.内核可装载模块就是可在内核运行时加载到内核的一组代码.通常 , 我们会在两个版本不同的内核上装载同一模块失败,即使是在两个相邻的补丁级(Patch Level)版本上.这是因为内核在引入可装载模块的同时,对模块采取了版本信息校验.这是一个与模块代码无关,却与内核相连的机制.该校验机

把握linux内核设计(三):下半部机制之软中断

[版权声明:尊重原创,转载请保留出处:blog.csdn.net/shallnet,文章仅供学习交流,请勿用于商业用途] 中断处理程序以异步方式执行,其会打断其他重要代码,其运行时该中断同级的其他中断会被屏蔽,并且当前处理器上所有其他中断都有可能会被屏蔽掉,还有中断处理程序不能阻塞,所以中断处理需要尽快结束.由于中断处理程序的这些缺陷,导致了中断处理程序只是整个硬件中断处理流程的一部分,对于那些对时间要求不高的任务,留给中断处理流程的另外一部分,也就是本节要讲的中断处理流程的下半部. 那哪些工作

Linux内核分析——理解进程调度时机跟踪分析进程调度与进程切换的过程

20135125陈智威 +原创作品转载请注明出处 +<Linux内核分析>MOOC课程http://mooc.study.163.com/course/USTC-1000029000 实验原理: 1.不同类型的进程有不同需求的调度需求:第一种分类:—I/O-bound:频繁的进行I/O,通常会花费很多时间等待I/O操作的完成—CPU-bound:计算密集型,需要大量的CPU时间进行运算第二种分类:—批处理进程:不必与用户交互,通常在后台运行:不必响应很快:—实时进程:有实时需求,不被低优先级的

Linux内核 TCP/IP、Socket参数调优

Doc1: /proc/sys/net目录 所有的TCP/IP参数都位于/proc/sys/net目录下(请注意,对/proc/sys/net目录下内容的修改都是临时的,任何修改在系统重启后都会丢失). http://www.360doc.com/content/16/0715/13/25686888_575696702.shtml /etc/sysctl.conf文件 /etc/sysctl.conf是一个允许你改变正在运行中的Linux系统的接口.它包含一些TCP/IP堆栈和虚拟内存系统的高

(转)Linux内核 TCP/IP、Socket参数调优

Doc1: /proc/sys/net目录 所有的TCP/IP参数都位于/proc/sys/net目录下(请注意,对/proc/sys/net目录下内容的修改都是临时的,任何修改在系统重启后都会丢失),例如下面这些重要的参数: 参数(路径+文件) 描述 默认值 优化值 /proc/sys/net/core/rmem_default 默认的TCP数据接收窗口大小(字节). 229376 256960 /proc/sys/net/core/rmem_max 最大的TCP数据接收窗口(字节). 131

Linux内核0.11 makefile文件说明

# # if you want the ram-disk device, define this to be the # size in blocks. # 如果要使用 RAM 就定义块的大小(注释掉了),这是一个编译时参数,如果定义了在下面会用到. RAMDISK = #-DRAMDISK=512 AS86 =as86 -0 -a #8006汇编的编译器和连接器.后面参数分别是: LD86 =ld86 -0 # -0 生成8086目标程序, -a 生成与gas 和 gld部分兼容的代码. AS

Linux内核0.11 bootsect文件说明

一.总体功能介绍 这是关于Linux-kernel-0.11中boot文件夹下bootsect.s源文件的说明,其中涉及到了一些基础知识可以参考这两篇文章. 操作系统启动过程 软盘相关知识和通过BIOS中断访问软盘 bootsect.s 代码是磁盘引导块程序,存储在磁盘的第一个扇区中(0面0道1扇区),在计算机上电BIOS自检后,BIOS 会吧引导扇区代码bootsect加载到内存0x90000处开并运行. bootsect代码主要完成以下几项工作: 加载从磁盘第二个扇区开始的4个扇区的内容(由

Linux内核系列—11.操作系统开发之ELF格式

ELF文件的结构如下图所示: ELF文件由4部分组成,分别是ELF头(ELF header).程序头表(Program header table).节(Sections)和节头表(Section header table). 实际上,一个文件中不一定包含全部这些内容,而且它们的位置也未必如上图所示这样安排,只有ELF头的位置是固定的,其余各部分的位置.大小等信息由ELF头中的各项值来决定. ELF header的格式如下代码所示: #define EI_NIDENT 16 typedef str

把握linux内核设计(四):下半部机制之tasklet

[版权声明:尊重原创,转载请保留出处:blog.csdn.net/shallnet,文章仅供学习交流,请勿用于商业用途] tasklet是利用软中断实现的一种下半部机制.tasklet相比于软中断,其接口更加简单方便,锁保护要求较低. tasklet由tasklet_struct结构体表示: struct tasklet_struct { struct tasklet_struct *next; //链表中下一个tasklet unsigned long state; //tasklet状态 a