有的时候在驱动程序中需要延迟某些操作的进行，最典型的操作就是在驱动程序的中断处理函数延迟操作。比如在DMA驱动中，当数据传输完毕之后会触发中断的，通常这时候会启动一个tasklet来完成耗时的操作，也就是中断的下半部，让中断尽早的返回。
linux的上下文切换就是进程线程的切换，也就是切换struct task_struct结构体，一个任务的上下文包括cpu的寄存器，内核栈等，由于1个cpu上的所有任务共享一套寄存器，所以在任务挂起的时候需要保存寄存器，当任务重新被调度执行的时候需要恢复寄存器。每种处理器都提供了硬件级别的上下文切换，比如x86架构下的TSS段，TSS段包括了一个任务执行的所需要的所有上下文，主要有：1.通用寄存器和段寄存器。2.标志寄存器EFLAGS,程序指针EIP，页表基地址寄存器CR3，任务寄存器和LDTR寄存器。3.I/O映射位图基地址和I/O位图信息。4.特权级0，1，2堆栈指针。5.链接到前一任务的链指针。所以上下文切换也很简单，直接用call或者jmp指令调度任务。同样ARM架构也有快速上下文切换技术。但是Linux为了适用更多的cpu架构没使用处理器相关的上下文切换技术，而是大部分通过软件实现。linux上下文切换就在schedule（）函数里，很多地方都会调用这个函数。scchedule函数前面大部分代码是和调度算法相关的，比如实时任务调度算法，O(1)调度算法（2.6.22版本被CFS调度算法取代），CFS调度算法等。经过前面的代码计算后找出下一个要执行的任务，然后开始执行上下文切换。先看一段linux2.6.18版本还使用O(1)调度算法的schedule函数代码：
Ftrace是Linux Kernel的官方tracing系统，支持Function trace、静态tracepoint、动态Tracepoint的跟踪，还提供各种Tracer，用于统计最大irq延迟、最大函数调用栈大小、调度事件等。
假设系统中有4个cpu， 同时有一个变量在各个CPU之间是共享的，每个cpu都有访问该变量的权限。
现如今，Linux处理器电源管理重点聚焦在处理器处于运行状态时对其进行电源管理，主要的技术是Cpufreq: 根据cpu的负载，实时的改变cpu的频率或这电压，同时管理处理器的性能水平和电源功耗等。相反当处理器处于空闲状态，也就是idle状态时的功耗也需要进行管理。也就是本文需要讨论的重点: Cpuidle。
今天突然想起前段时间学习的一篇博客，是oaktable的Charles Hooper所写，链接为： https://hoopercharles.wordpress.com/2010/02/19/what-is-the-meaning-of-the-cpu-column-in-an-explain-plan/ 自己也趁机消化了一下。对于执行计划中的 列Cost (%CPU)，其中的%CPU的含义很少有人能够说得清楚，于是Charles Hooper写了上面的文章来解释。 对于执行计划的信息都会放入plan_t
也许大家会觉得奇怪：为什么Linux kernel把对ARM big·Lttile的支持放到了cpufreq的框架中？
Recovery of uncorrected recoverable（UCR） errors是MCA的一个增强特性，它针对部分硬件无法恢复的故障，提供软件隔离、恢复的机会。UCR errors表示硬件已检测到错误并发出信号通知到软件，软件执行了某些恢复操作（不会出现错误污染、扩散）后，系统可以继续运行。
O(n)调度器采用一个runqueue运行队列来管理所有可运行的进程，在主调度schedule函数中会选择一个优先级最高，也就是时间片最大的进程来运行，同时也会对喜欢睡眠的进程做一些补偿，去增加此类进程的时间片。当runqueue运行队列中无进程可选择时，则会对系统中所有的进程进行一次重新计算时间片的操作，同时也会对剩余时间片的进程做一次补偿。
前言： 在《clocksource的管理和虚拟化》中，大概分析了kvm clock，tsc，hpet等clock source。其中尤其是kvm clock计算尤其复杂。其目的就在于让Guest中的clock更加准确。但是问题还没有完，Guest只是在Host中的一个进程，还是会发生时钟跳变。下文具体分析。 分析： 1，analysis 当前Host的墙上时间是HWT1，此时Guest中的墙上时间GWT1，如果是同一个时区的话，此时HWT1和GWT1是相等的。 如果此时Host中发生了调度，Guest所
SELECT EXECUTIONS , DISK_READS, BUFFER_GETS, ROUND((BUFFER_GETS-DISK_READS)/BUFFER_GETS,2) Hit_radio, ROUND(DISK_READS/EXECUTIONS,2) Reads_per_run, SQL_TEXT FROM V$SQLAREA WHERE EXECUTIONS>0 AND BUFFER_GETS > 0 AND (BUFFER_GETS-DISK_READS)/BUFFER_GETS
X86-64 架构，Kernel Ver：Centos7 3.10.0-693.el7.x86_64
进程切换是一个复杂的过程，本文不准备详细描述整个进程切换的方方面面，而是关注进程切换中一个小小的知识点：TLB的处理。为了能够讲清楚这个问题，我们在第二章描述在单CPU场景下一些和TLB相关的细节，第三章推进到多核场景，至此，理论部分结束。在第二章和第三章，我们从基本的逻辑角度出发，并不拘泥于特定的CPU和特定的OS，这里需要大家对基本的TLB的组织原理有所了解，具体可以参考本站的《TLB操作》一文。再好的逻辑也需要体现在HW block和SW block的设计中，在第四章，我们给出了linux4.4.6内核在ARM64平台上的TLB代码处理细节（在描述tlb lazy mode的时候引入部分x86架构的代码），希望能通过具体的代码和实际的CPU硬件行为加深大家对原理的理解。
在内存管理的上下文中, 初始化(initialization)可以有多种含义. 在许多CPU上, 必须显式设置适用于Linux内核的内存模型. 例如在x86_32上需要切换到保护模式, 然后内核才能检测到可用内存和寄存器.
作者简介：伟林，中年码农，从事过电信、手机、安全、芯片等行业，目前依旧从事Linux方向开发工作，个人爱好Linux相关知识分享。 0.背景 ftrace的功能非常强大，可以在系统的各个关键点上采集数据用以追踪系统的运行情况。既支持预设的静态插桩点(trace event)，也支持每个函数的动态插桩(function tracer)。还可以利用动态插桩来测量函数的执行时间(function graph tracer)。关于ftrace的详细操作和原理分析可以参考Linux ftrace一文。 本文的主要目的
前面分析了memblock算法、内核页表的建立、内存管理框架的构建，这些都是x86处理的setup_arch()函数里面初始化的，因地制宜，具有明显处理器的特征。而start_kernel()接下来的初始化则是linux通用的内存管理算法框架了。
本文是为那些希望非常深层次的理解RCU的骨灰级黑客准备的。这些黑客应当首先阅读《深入理解RCU》系列文章的第1~6篇。骨灰级代码狂也可能有兴趣直接看看本文。
在之前的ARMv8-A的异常文章中提到，ARMv8-A将中断也当做一种异常，中断分为IRQ和FIQ
softirqs 是在 Linux 内核编译时就确定好的，例如网络收包对应的 NET_RX_SOFTIRQ 软中断。因此是一种静态机制。如果想加一种新 softirq 类型，就需要修改并重新编译内核。
RPS和RFS是google贡献的两个补丁，在2.6.35版本中，正式被合并入了内核。这两个补丁总体来说，并不算复杂，实际上很多网络设备厂商早已在自己的产品中，有了类似的应用。但这个涉及到厂商的主营业务，所以不会做任何开源。
软中断的出现和linux系统对中断的划分是分不开的。linux系统将整个中断处理过程分为了两部分，分别为上半部(Top Half)和下半部(Bottom Half)，之所以要这样分是因为关闭中断的时间不能过长，也就是在关闭中断期间尽可能少干事，否则影响整个系统的性能。所以linux系统将中断处理分为两部分，在上半部全程关闭中断，下半部打开中断。而在上半部主要干一些和硬件有关的操作，速度快，在下部分做一些耗时的操作。这样一来既能保证系统效率又能处理各种中断。
在上一篇文章中我们通过一个简单的例子大概描述了如何创建SLUB缓存，如何分配一个object。本文详细描述下涉及的结构体，从结构体的描述中就可以大概理解slub的工作原理了。
Ftrace设计作为一个内部的tracer提供给系统的开发者和设计者，帮助他们弄清kernel正在发生的行为，它能够调式分析延迟和性能问题。对于前一章节，我们学习了Ftrace发展到现在已经不仅仅是作为一个function tracer了，它实际上成为了一个通用的trace工具的框架
我们拆解完了 Linux 网络包的接收过程，也搞定了网络包的发送过程。内核收发网络包整体流程就算是摸清楚了。
在自动驾驶中，需要大量的sensor信息上传到服务器进行训练。即使在车辆的行驶过程中也需要相关的sensor信息进行融合，感知。而sensor的信息可能来自不同的域，这样就需要高速稳定的网络来提供基础服务。对RX 和TX 提供了下面技术，
中断描述符表简单来说说是定义了发生中断/异常时，CPU按这张表中定义的行为来处理对应的中断/异常。
0.前言 为提升信鸽基础服务质量，笔者就网络收包全流程进行了内容整理。 网络编程中我们接触得比较多的是socket api和epoll模型，对于系统内核和网卡驱动接触得比较少，一方面可能我们的系统没有需要深度调优的需求，另一方面网络编程涉及到硬件，驱动，内核，虚拟化等复杂的知识，使人望而却步。网络上网卡收包相关的资料也比较多，但是比较分散，在此梳理了网卡收包的流程，分享给大家，希望对大家有帮助，文中引用了一些同事的图表和摘选了网上资料，在文章最后给出了参考文献与部分来源，感谢这些作者的分享。 1.整体流程
本文作者张彦飞，原题“127.0.0.1 之本机网络通信过程知多少 ”，首次发布于“开发内功修炼”，转载请联系作者。本次有改动。
这里深度理解一下在Linux下网络包的接收过程，为了简单起见，我们用udp来举例，如下：
关于workqueue机制的介绍文章比较多，主要就几个核心的数据结构：work_struct/worker/workqueue/worker_pool/
程磊，某手机大厂系统开发工程师，阅码场荣誉总编辑，最大的爱好是钻研Linux内核基本原理。
正如我在朋友圈里所说的，最近我又对网络虚拟化技术产生了浓厚的兴趣。迫切想搞明白在 Docker 等虚拟技术下，网络底层是如何运行的。
crash 是目前广泛使用的 linux 内核崩溃转储文件的分析工具，掌握 crash 的使用技巧，对于分析定位内核崩溃的问题，有着非常重要的作用。本文首先介绍了 crash 的基本概念和安装方法，其次详细介绍了如何使用 crash 工具分析内核崩溃转储文件，包括各种常用调试命令的使用方法，最后以几个实际工作中遇到的真实案例向读者展示了 crash 的强大功能。在这篇文章中，既有详细的工具使用方法，又有丰富的实际案例分析，相信您读过以后定会受益匪浅。
我们之前讲了在memblock完成之后, 内存初始化开始进入第二阶段, 第二阶段是一个漫长的过程, 它执行了一系列复杂的操作, 从体系结构相关信息的初始化慢慢向上层展开, 其主要执行了如下操作
当碰到内核线程的资源使用异常时，很多常用的进程级性能工具，并不能直接用到内核线程上。这时，我们就可以使用内核自带的 perf 来观察它们的行为，找出热点函数，进一步定位性能瓶颈。不过，perf 产生的汇总报告并不直观，所以我通常也推荐用火焰图来协助排查。
最近遇到一个kworker问题，callstack如下，线程adas的陷入kernel space后会schedule_work调用一个while(1)的worker，kill adas后重新启动adas后adas线程会在调用dma_alloc_coherent的时候block住
1. 启动过程中的内存初始化 首先我们来看看start_kernel是如何初始化系统的, start_kerne定义在init/main.c?v=4.7, line 479 其代码很复杂, 我们只截取
Ftrace是Function Trace的简写，由 Steven Rostedt 开发的，从 2008 年发布的内核 2.6.27 中开始就内置了。
因为要对百万、千万、甚至是过亿的用户提供各种网络服务，所以在一线互联网企业里面试和晋升后端开发同学的其中一个重点要求就是要能支撑高并发，要理解性能开销，会进行性能优化。而很多时候，如果你对网络底层的理解不深的话，遇到很多线上性能瓶颈你会觉得狗拿刺猬，无从下手。
在多核系统中，为了更好的利用多CPU并行能力，进程调度器可以将进程负载尽可能的平均到各个CPU上。再具体实现中，如何选择将进程迁移到的目标CPU，除了考虑各个CPU的负载平衡，还需要将Cache利用纳入权衡因素。同时，对于进程A唤醒进程B这个模型，还做了特殊的处理。本文分析以Centos kernel 3.10.0-975源码为蓝本。
因为要对百万、千万、甚至是过亿的用户提供各种网络服务，所以在一线互联网企业里面试和晋升后端开发同学的其中一个重点要求就是要能支撑高并发，要理解性能开销，会进行性能优化。而很多时候，如果你对Linux底层的理解不深的话，遇到很多线上性能瓶颈你会觉得狗拿刺猬，无从下手。
操作系统内核对应用开发工程师来说就像一个黑盒，似乎很难窥探到其内部的运行机制。其实Linux内核很早就内置了一个强大的tracing工具：Ftrace，它几乎可以跟踪内核的所有函数，不仅可以用于调试和分析，还可以用于观察学习Linux内核的内部运行。虽然Ftrace在2008年就加入了内核，但很多应用开发工程师仍然不知道它的存在。本文就给你介绍一下Ftrace的基本使用。
在前面学习了CFS调度的原理和主要的数据结构，今天我们就来进入代码分析环节。当然了代码分析只看主要主干不看毛细，同时我们也是根据一个进程是如何被调度的思路来分析一些重要的代码。
对每个人而言，真正的职责只有一个：找到自我。然后在心中坚守其一生，全心全意，永不停息。所有其它的路都是不完整的，是人的逃避方式，是对大众理想的懦弱回归，是随波逐流，是对内心的恐惧 ——赫尔曼·黑塞《德米安》
我们通过 Linux 的命名空间为新创建的进程隔离了文件系统、网络并与宿主机器之间的进程相互隔离，但是命名空间并不能够为我们提供物理资源上的隔离，比如 CPU 或者内存，如果在同一台机器上运行了多个对彼此以及宿主机器一无所知的『容器』，这些容器却共同占用了宿主机器的物理资源。
Redis 服务端的总体请求量从年初最开始日访问量百亿次级别上涨到高峰时段的万亿次级别，给运维和架构团队都带来了极大的挑战。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
云直播
对象存储
