异常接管是操作系统对在运行期间发生异常的情况进行处理的一系列动作,譬如打印异常发生时当前函数调用栈信息、 cpu现场信息、任务的堆栈情况等。
原创作品转载请注明出处https://github.com/mengning/linuxkernel/
| 导语 本文主要是讲Linux的调度系统, 由于全部内容太多,分三部分来讲,调度可以说是操作系统的灵魂,为了让CPU资源利用最大化,Linux设计了一套非常精细的调度系统,对大多数场景都进行了很多优化,系统扩展性强,我们可以根据业务模型和业务场景的特点,有针对性的去进行性能优化,在保证客户网络带宽前提下,隔离客户互相之间的干扰影响,提高CPU利用率,降低单位运算成本,提高市场竞争力。欢迎大家相互交流学习!
最近在研究异步消息处理, 突然想起linux内核的中断处理, 里面由始至终都贯穿着”重要的事马上做, 不重要的事推后做”的异步处理思想. 于是整理一下~ 第一阶段 获取中断号 每个CPU都有响应中断的
前面的几篇文章里讨论过了进程上下文切换和系统调用对系统性能的影响,我们今天再来看另外一个CPU吃货,那就是软中断。
今天分享一篇经典Linux协议栈文章,主要讲解Linux网络子系统,看完相信大家对协议栈又会加深不少,不光可以了解协议栈处理流程,方便定位问题,还可以学习一下怎么去设计一个可扩展的子系统,屏蔽不同层次的差异。
文中的调优思路无论是 php, java, 还是其他任何语言都是用. 如果你有 php 使用经验, 那肯定就更好了
本文将介绍在Linux系统中,以一个UDP包的接收过程作为示例,介绍数据包是如何一步一步从网卡传到进程手中的。
导语:STGW作为公司七层接入网关,在云和自研业务中承担多种网络协议接入与转发的功能,由于业务数量庞大、接入形式多样、网络环境复杂,会遇到一些很有挑战的疑难杂症。某次业务出现了流量突然下降,此时用户侧也有延迟上升和重试增多的问题。在团队自研的秒级监控助力下,我们从CPU软中断热点入手追查,发现了内核listen port哈希机制存在消耗过高问题,但热点只出现在部分核心上,接着在网卡多队列、内核Receive Packet Steering(RPS)上发现了负载均衡策略的缺陷,找出最终原因后我们在硬件和
因为要对百万、千万、甚至是过亿的用户提供各种网络服务,所以在一线互联网企业里面试和晋升后端开发同学的其中一个重点要求就是要能支撑高并发,要理解性能开销,会进行性能优化。而很多时候,如果你对Linux底层的理解不深的话,遇到很多线上性能瓶颈你会觉得狗拿刺猬,无从下手。
作为网络领域的开发人员,我们经常要与Linux的数据报文打交道,一定要搞清楚数据报文是从何而来,又是如何离去。以前针对这个主题写过一些文章(主要是从源码角度),这次会更重视流程示意图(在细节上必然有所简化),争取在一篇文章中,就让大家理清数据报文的来龙去脉。
通过前面的文章我们已经了解了「数据包从HTTP层->TCP层->IP层->网卡->互联网->目的地服务器」这中间涉及的知识。
中断其实就是由硬件或软件所发送的一种称为IRQ(中断请求)的信号。中断允许让设备,如键盘,串口卡,并口等设备表明它们需要CPU。
因为要对百万、千万、甚至是过亿的用户提供各种网络服务,所以在一线互联网企业里面试和晋升后端开发同学的其中一个重点要求就是要能支撑高并发,要理解性能开销,会进行性能优化。而很多时候,如果你对网络底层的理解不深的话,遇到很多线上性能瓶颈你会觉得狗拿刺猬,无从下手。
软中断、tasklet和工作队列并非Linux内核中一直存在的机制,而是由更早版本号的内核中的“下半部”(bottom half)演变而来。
比如说你订了一份外卖,但是不确定外卖什么时候送到,也没有别的方法了解外卖的进度, 但是,配送员送外卖是不等人的,到了你这儿没人取的话,就直接走人了;所以你只能苦苦等着,时不时去门口看看外卖送到没,而不能干其他事情;不过呢,如果在订外卖的时候,你就跟配送员约定好,让他送到后给你打个电话,那你就不用苦苦等待了,就可以去忙别的事情,直到电话一响,接电话、取外卖就可以了、
CS部分后面又4个0,相当于是左移了4位。总之就是要让CS左移4位之后加上EIP来得到要跳转的地址。
1、CPU使用率不高但是软中断已经到了10%,从非idle状态的全部用在了软中断上面。
实时系统要求对事件的响应时间不能超过规定的期限,响应时间是指从某个事件发生到负责处理这个事件的进程处理完成的时间间隔,最大响应时间应该是确定的、可以预测的。
当时有些地方写的比较笼统,然后我「把 Linux 接收+发送网络包的流程」这部分内容完善了下,现在重新分享给大家。
Linux 具有功能丰富的网络协议栈,并且兼顾了非常优秀的性能。但是,这是相对的。单纯从网络协议栈各个子系统的角度来说,确实做到了功能与性能的平衡。不过,当把多个子系统组合起来,去满足实际的业务需求,功能与性能的天平就会倾斜。
我们拆解完了 Linux 网络包的接收过程,也搞定了网络包的发送过程。内核收发网络包整体流程就算是摸清楚了。
从本质上来讲,中断是一种电信号,当设备有某种事件发生时,它就会产生中断,通过总线把电信号发送给中断控制器。
实时分为硬实时和软实时,硬实时要求绝对保证响应时间不超过期限,如果超过期限,会造成灾难性的后果,例如汽车在发生碰撞事故时必须快速展开安全气囊;软实时只需尽力使响应时间不超过期限,如果偶尔超过期限,不会造成灾难性的后果.
最近,某团外卖被爆出大数据杀熟,所谓的大数据杀熟指的是平台利用户的数据,分析你是否是钱多的人,或者是否是不纠结价格的人,如果是,那么你买同样的物品会比普通用户贵一点,一般这种没有特地去对比价格是很难发现的,所以平台就利用了这点额外赚一些钱。说来很可笑,我们作为平台的资深用户,竟然被平台背后偷偷捞一笔。
很久没有写技术文章了,做码农难,做养娃的码农更难,趁着娃看动画片的机会,受着王菲童鞋《我和我的祖国》歌唱精神的鼓舞,我要来说几句。
在Hi3559A中,liteos是用于Cortex-A53,用于处理MPP 媒体业务逻辑的;
当用户态进程发起一个系统调用, CPU 将切换到 内核态 并开始执行一个 内核函数 。 内核函数负责响应应用程序的要求,例如操作文件、进行网络通讯或者申请内存资源等。
处理外部事件是 CPU 必须要做的事,因为 CPU 和外设的不平等性导致外设的事件被 CPU 当作是外部事件,其实它们是平等的,只不过冯氏机器不这么认为罢了,既然要处理外部事件,那么就需要一定的方法,方法不止一种,大致有中断和轮询以及一种 混杂又复杂的方式,也就是DMA方式。中断是 CPU 被动处理的一种方式,也就是说 CPU 不知道何时中断,只要有了中断就会通知 CPU,而 CPU 此时必须停 下一切来处理,而轮询是 CPU 主动查询并处理的过程,CPU 隔一会查询一下外设看有没有事情可做。
0.前言 为提升信鸽基础服务质量,笔者就网络收包全流程进行了内容整理。 网络编程中我们接触得比较多的是socket api和epoll模型,对于系统内核和网卡驱动接触得比较少,一方面可能我们的系统没有需要深度调优的需求,另一方面网络编程涉及到硬件,驱动,内核,虚拟化等复杂的知识,使人望而却步。网络上网卡收包相关的资料也比较多,但是比较分散,在此梳理了网卡收包的流程,分享给大家,希望对大家有帮助,文中引用了一些同事的图表和摘选了网上资料,在文章最后给出了参考文献与部分来源,感谢这些作者的分享。 1.整体流程
这里深度理解一下在Linux下网络包的接收过程,为了简单起见,我们用udp来举例,如下:
F-Stack是一个全用户态(kernel bypass)的高性能的网络接入开发包,基于DPDK、FreeBSD协议栈、微线程接口等,适用于各种需要网络接入的业务,用户只需要关注业务逻辑,简单的接入F-Stack即可实现高性能的网络服务器。 本文介绍F-Stack的详细架构及如何解决内核协议栈面临的问题。 传统内核协议栈的性能瓶颈 在传统的内核协议栈中,网络包处理存在诸多瓶颈,严重影响网络包的收发性能。性能瓶颈主要包括以下几个方面 局部性失效 - 一个数据包的处理可能跨多个CPU核心、缓存失效、NUM
本文作者张彦飞,原题“127.0.0.1 之本机网络通信过程知多少 ”,首次发布于“开发内功修炼”,转载请联系作者。本次有改动。
Linux内核的软中断("softirq")机制有些奇怪,在早期的Linux和处理机制下比较晦涩,且仅有极少的内核开发人员会直接接触软中断。然而它是内核的大多数重要处理的核心。在某些场景下,软中断会以一种不合时宜的方式出现。特别是内核的实时抢占补丁集经常会与软中断产生冲突,该补丁集的最新版本提供了一种解决产生软中断问题的方法,值得一看。
在之前的文章中,讲解中断处理相关的概念的时候,提到过有些任务不是紧急的,可以延后一段时间执行。因为中断服务例程都是顺序执行的,在响应一个中断的时候不应该被打断。相反,这些可延时任务执行时,可以使能中断。那么,将这些任务从中断处理程序中剥离出来,可以有效地保证内核对于中断响应时间尽可能短。这对于时间苛刻的应用来说,这是一个很重要的属性,尤其是那些要求中断请求必须在毫秒级别响应的应用。
因为epoll没有论文,就说说kqueue是怎么做的吧,kqueue会根据socket绑定的knote链表(每个监听的kqueue都可能创建一个knote),将knote通过反向指针获得kqueue,将knote加入kqueue的就绪队列末尾。如果此时恰好有进程正在监听的话,将会唤醒进程,kqueue会被扫描,并从就绪队列处获得所有的event,从而了解已经就绪的所有socket。
在现代操作系统里,同一时间可能有多个内核执行流在执行,因此内核其实像多进程多线程编程一样也需要一些同步机制来同步各执行单元对共享数据的访问,尤其是在多处理器系统上,更需要一些同步机制来同步不同处理器上的执行单元对共享的数据的访问。在主流的Linux内核中包含了如下这些同步机制包括:
设备的中断会打断内核进程中的正常调度和运行,系统对更高吞吐率的追求势必要求中断服务程序尽量短小精悍。但是,这个良好的愿望往往与现实并不吻合。在大多数真实的系统中,当中断到来时,要完成的工作往往并不会是短小的,它可能要进行较大量的耗时处理。 下图描述了Linux内核的中断处理机制。为了在中断执行时间尽量短和中断处理需完成的工作尽量大之间找到一个平衡点,Linux将中断处理程序分解为两个半部:顶半部和底半部。
大内核锁(BKL)现在已经成为了一个遥远的记忆,但在那么多年里,它都是内核开发社区面临的一项棘手问题。然而 BKL 的终结并不意味着内核没有其他有问题的锁。近来,已经有一些关注转向了软中断锁(software-interrupt lock)或“下半部锁”(bottom half lock),因为它可能会在实时系统上导致延迟。Frederic Weisbecker 正在采取最新行动来减小这个锁的影响范围,该方法就是基于移除 BKL 时所采取的方法。
所以我们会比较好了解CPU密集型,需要大量计算资源,会非常消耗cpu,I/O密集型需要等待I/O,会有大量的不可中断进程,
https://www.cnblogs.com/poloyy/category/1814570.html
今天分享一位同学的腾讯天美面经,对的就是那个王者荣耀部门的天美,问的问题很细节,会追着基础问题一直深问,直到你不会,才会换话题,主要注重计算机基础,操作系统这方面了。
为了使得多种设备能通过网络相互通信,和为了解决各种不同设备在网络互联中的兼容性问题,国际标标准化组织制定了开放式系统互联通信参考模型(open System Interconnection Reference Model),也就是 OSI 网络模型,该模型主要有 7 层,分别是应用层、表示层、会话层、传输层、网络层、数据链路层以及物理层。
panic 究竟是啥?看似显而易见的问题,但是却回答不出个所以然来。奇伢分两个章节来彻底搞懂 panic 的知识:
半年前我以源码的方式描述了网络包的接收过程。之后不断有粉丝提醒我还没聊发送过程呢。好,安排!
软中断分析最近工作繁忙,没有时间总结内核相关的一些东西。上次更新博客到了linux内核中断子系统。这次总结一下软中断,也就是softirq。之后还会总结一些tasklet、工作队列机制。 1.为什么要软中断 编写驱动的时候,一个中断产生之后,内核在中断处理函数中可能需要完成很多工作。但是中断处理函数的处理是关闭了中断的。也就是说在响应中断时,系统不能再次响应外部的其它中断。这样的后果会造成有可能丢失外部中断。于是,linux内核设计出了一种架构,中断函数需要处理的任务分为两部分,一部分在中断处理函数中执
领取专属 10元无门槛券
手把手带您无忧上云