手机版
你好,游客 登录 注册 搜索
背景:
阅读新闻

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

[日期:2015-07-08] 来源:Linux社区  作者:dog250 [字体: ]

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处理大量的数据包,那就开启它,不管怎样,这只是一个用法和配置的问题,何时开启,以及份额设置多少,需要一个事前采样的过程。

本文永久更新链接地址http://www.linuxidc.com/Linux/2015-07/119592.htm

linux
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款