Linux-Kernel

概述IO 提早问题简直是每个生产零碎都会或多或少遇到的问题。尽管当初 NVMe + SSDs 曾经能够达到 10Gbytes/s 的呑吐量，价格也十分亲民。但 IO 提早问题不会隐没。因为： 一些基于网络的的存储计划，如 Ceph，人造地有不稳定性SSD / RAIN Controller 自身的不稳定性在 Linux 下，传统地，咱们有 iostat / sar 等等工具能够看零碎级、存储设备级的问题。但均不能通知你以下几点： 产生 IO 提早时，过程/线程实际上的挂起时长过程/线程因 IO 提早挂起过几次这些问题，在 Linux 下因为写操作的异步落盘 pdflush 线程，问题变得更加难答复。当然，你能够用新技术 BPF，但不肯定须要这个牛刀。 有同学会问，晓得 IO 提早对线程的理论影响有什么用？答案可见我另外的两篇文章： eBPF 求证坊间风闻：Java GC 日志可导致整个 JVM 服务卡顿？eBPF 求证坊间风闻：mmap + Java Safepoint 可导致整个 JVM 服务卡顿？基本原理Linux 有很多暗藏个性，其中 Per-task statistics interface 与其下层的 Delay accounting 能够为每个线程减少一些 delay 的统计指标。 内核源码中，也有读取相干指标的 demo 利用源码。以下是一个操作示例： sudo sysctl kernel.task_delayacct=1# run your appsudo ./getdelays -t 608452 -d -iprint delayacct stats ONprinting IO accountingTGID 608452CPU count real total virtual total delay total delay average 60043 4332000000 4670325102 49110971 0.001msIO count delay total delay average 199 200090856599 1005msSWAP count delay total delay average 0 0 0msRECLAIM count delay total delay average 0 0 0msTHRASHING count delay total delay average 0 0 0msCOMPACT count delay total delay average 0 0 0msWPCOPY count delay total delay average 201 313245 0ms: read=0, write=0, cancelled_write=0Ubuntu 如同没有这个 getdelays 工具的 apt 包，须要本人编译。我是个懒人，所以我抉择了另一个查看这些指标的办法。 ...

本文基于内核 5.4 版本源码探讨之前有不少读者给笔者留言，心愿笔者写一篇文章介绍下 mmap 内存映射相干的常识体系，之所以迟迟没有动笔，是因为 mmap 这个零碎调用看上去简略，实际上并不简略，能够说是非常复杂的一个零碎调用。 如果想要给大家把 mmap 背地的技术实质，正确地，清晰地还原进去，还是有肯定难度的，因为 mmap 这一个零碎调用就能撬动起整个内存管理系统，文件系统，页表体系，缺页中断等一大片的背景常识，波及到的知识面广且繁冗。 侥幸的是这一整套的背景常识，笔者曾经在 《聊聊 Linux 内核》 系列文章中为大家具体介绍过了，所以当初是时候开始动笔了，不过大家不须要放心，尽管波及到的背景常识比拟多，然而在前面的相干章节里，笔者还会为大家从新交代。 在上一篇文章 《一步一图带你构建 Linux 页表体系》 中，笔者为大家介绍了内存映射最为外围的内容 —— 页表体系。通过一步一图的形式为大家展现了整个页表体系的演进过程，并在这个过程中逐渐揭开了整个页表体系的全貌。 本文的内容仍然是内存映射相干的内容，这一次笔者会带着大家围绕页表这个最为外围的体系，在页表的外围进行内存映射相干常识的介绍，外围目标就是彻底为大家还原内存映射背地的技术实质，由浅入深地给大家讲透彻，弄明确。 在咱们正式开始明天的内容之前，笔者想首先抛出几个问题给大家思考，倡议大家带着这几个问题来浏览接下来的内容，咱们独特来将这些迷雾一层一层地缓缓拨开，直到还原出内存映射的实质。 既然咱们是在探讨虚拟内存与物理内存的映射，那么首先你得有虚拟内存，你也得有物理内存吧，在这个根底之上，能力探讨两者之间的映射，而物理内存是怎么来的，笔者曾经通过前边文章 《深刻了解 Linux 物理内存调配全链路实现》 介绍的十分分明了，那虚拟内存是怎么来的呢 ？内核调配虚拟内存的过程是怎么的呢？咱们晓得内存映射是依照物理内存页为单位进行的，而在内存治理中，内存页次要分为两种：一种是匿名页，另一种是文件页，这一点笔者曾经在 《一步一图带你深刻了解 Linux 物理内存治理》 一文中重复讲过很屡次了。依据物理内存页的类型分类，内存映射天然也分为两种：一种是虚拟内存对匿名物理内存页的映射，另一种是虚拟内存对文件页的映射。对于文件映射，大家或多或少在网上看到过这样的阐述——" 通过内存文件映射能够将磁盘上的文件映射到内存中，这样咱们就能够通过读写内存来实现磁盘文件的读写 "。对于这个阐述，如果对内存治理和文件系统不相熟的同学，可能感到这句话十分的神奇，会有这样的一个疑难，内存就是内存啊，磁盘上的文件就是文件啊，这是两个齐全不同的货色，为什么说读写内存就相当于读写磁盘上的文件呢 ？内存文件映射在内核中到底产生了什么 ？咱们常常谈到的内存映射，到底映射的是什么？在上篇文章中笔者只是为大家展现了整个页表体系的全貌，以及页表体系一步一步的演进过程，然而在过程被创立进去之后，内核也仅是会为过程调配一张全局页目录表 PGD（Page Global Directory）而已，此时过程虚拟内存空间中只存在一张顶级页目录表，而在上图中所展现的四级页表体系中的下层页目录 PUD（Page Upper Directory），两头页目录 PMD（Page Middle Directory）以及一级页表是不存在的，那么上图展现的这个页表残缺体系是在什么时候，又是如何被一步一步构建进去的呢？本文的宗旨就是围绕上述这几个问题来开展的，那么从何谈起呢 ？笔者想了一下，还是应该从咱们最为相熟的，在用户态常常接触到的内存映射零碎调用 mmap 开始聊起~~~ 1. 详解内存映射零碎调用 mmap#include <sys/mman.h>void* mmap(void* addr, size_t length, int prot, int flags, int fd, off_t offset);// 内核文件：/arch/x86/kernel/sys_x86_64.cSYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, len, unsigned long, prot, unsigned long, flags, unsigned long, fd, unsigned long, off)mmap 内存映射里所谓的内存其实指的是虚拟内存，在调用 mmap 进行匿名映射的时候（比方进行堆内存的调配），是将过程虚拟内存空间中的某一段虚拟内存区域与物理内存中的匿名内存页进行映射，当调用 mmap 进行文件映射的时候，是将过程虚拟内存空间中的某一段虚拟内存区域与磁盘中某个文件中的某段区域进行映射。 ...

Cloud Kernel SIG（Special Interest Group）：撑持龙蜥内核版本的研发、公布和服务，提供生产可用的高性价比内核产品。 01 SIG 整体停顿Anolis 8.8 镜像公布，默认搭载 ANCK 5.10-013 版本。Anolis 23 滚动内核更新至 6.1LTS。kABI 文档公布与 kABI 构造体预留合入。Cloud Kernel 门禁更新。02 Anolis 8.8 镜像默认内核切换至 5.10-013 版本Anolis 8.8 发行版默认内核由 4.19 内核切换到 5.10 内核。默认搭载的内核版本是 5.10.134-13.an8，能够在零碎内执行下列命令查看对应的内核版本信息。 $ uname -r5.10.134-13.an8.x86_64留神，如果是从 Anolis OS 8.8 以前的镜像版本升级而来，默认内核版本不会主动降级到 5.10 内核。 5.10-013 内核版本更新包含： 反对内核 CVE 修复。修复了 CVE-2022-32250，CVE-2022-34918 等重要的 CVE 破绽。反对用户态 /dev/ioasid。SWIOTLB 机制性能优化。virtio-net 关上 napi.tx 优化 TCP Small Queue 性能。反对 AST2600 PCIe 2D VGA Driver。反对 FT2500 处理器。反对动静开启 Group identity 个性。Arm64 平台默认内核启动。cmdline 调整增加 Compact Numa Aware（CNA）spinlock 性能反对。丰盛 Arm64 的 perf mem 和 perf c2c 性能。fsck.xfs 反对日志复原。hugetext 自适应按需大页。反对 SGX 动态内存治理。使能 wireguard 模块。03 Anolis 23 滚动内核降级至 6.1LTSAnolis 23 仓库地址：https://gitee.com/anolis/anck-next ...

本文摘自我的《Mark’s DevOps 雜碎》中的 《ELF 格局简述》。如图片不清，可转回原处。引为何要钻研 ELF 格局？因为想深刻点学习 eBPF ，充分利用它的个性，而非只利用它的名声，ELF 格局是跳不过的。 ELF 格局简述程序代码被编译和链接成蕴含二进制计算机指令的可执行文件。而可执行文件是有格局标准的，在 Linux 中，这个标准叫 Executable and linking format (ELF)。ELF 中蕴含二进制计算机指令、静态数据、元信息。 静态数据 - 咱们在程序中 hard code 的货色数据，如字串常量等二进制计算机指令汇合，程序代码逻辑生成的计算机指令。代码中的每个函数都在编译时生成一块指令，而链接器负责把一块块指令间断排列到输入的 ELF 文件的 .text section（区域） 中。元信息，可再细分为两类： 通知操作系统，如何加载和动静链接可执行文件，实现过程内存的初始化。一些非运行期必须，但能够帮忙定位问题的信息。如 .symtab section视图ELF 文件提供 2 个不同的视图（视角）： 链接视图(Linking view) - 对应 section header table 通知操作系统，动静链接可执行文件，实现过程内存的初始化。同时也为调试器提供一些元信息。 执行视图(execution view) - 对应 program header table(segment header table) 通知操作系统，如何加载可执行文件，实现过程内存的初始化。一个可执行的 ELF，肯定有program header table 从二进制串看，一个典型的 ELF 文件长这样： <p align = "center">典型的 ELF 文件格式例子 (图源自 [Computer Systems - A Programmer’s Perspective])</p> ...

前文回顾在上篇文章 《深刻了解 Linux 物理内存治理》中，笔者具体的为大家介绍了 Linux 内核如何对物理内存进行治理以及相干的一些内核数据结构。 在介绍物理内存治理之前，笔者先从 CPU 的角度开始，介绍了三种 Linux 物理内存模型：FLATMEM 平坦内存模型，DISCONTIGMEM 非间断内存模型，SPARSEMEM 稠密内存模型。 随后笔者又带大家站在一个新的视角上，把物理内存看做成一个整体，从 CPU 拜访物理内存以及 CPU 与物理内存的绝对地位变动的角度介绍了两种物理内存架构：一致性内存拜访 UMA 架构，非一致性内存拜访 NUMA 架构。 在 NUMA 架构下，只有 DISCONTIGMEM 非间断内存模型和 SPARSEMEM 稠密内存模型是可用的。而 UMA 架构下，后面介绍的三种内存模型能够配置应用。无论是 NUMA 架构还是 UMA 架构在内核中都是应用雷同的数据结构来组织治理的，在内核的内存治理模块中会把 UMA 架构当做只有一个 NUMA 节点的伪 NUMA 架构。 这样一来这两种架构模式就在内核中被对立治理起来，咱们基于这个事实，深刻分析了内核针对 NUMA 架构下用于物理内存治理的相干数据结构：struct pglist_data （NUMA 节点），struct zone（物理内存区域），struct page（物理页）。 上图展现的是在 NUMA 架构下，NUMA 节点与物理内存区域 zone 以及物理内存页 page 之间的档次关系。 物理内存被划分成了一个一个的内存节点（NUMA 节点），在每个 NUMA 节点外部又将其所治理的物理内存依照性能不同划分成了不同的内存区域 zone ，每个内存区域 zone 治理一片用于具体性能的物理内存页 page，而内核会为每一个内存区域调配一个搭档零碎用于治理该内存区域下物理内存页 page 的调配和开释。 ...

1. 前文回顾在上篇文章 《深刻了解 Linux 虚拟内存治理》 中，笔者别离从过程用户态和内核态的角度具体深刻地为大家介绍了 Linux 内核如何对过程虚拟内存空间进行布局以及治理的相干实现。在咱们深刻了解了虚拟内存之后，那么何不顺带着也探秘一下物理内存的治理呢？ 所以本文的目标是在深刻了解虚拟内存治理的根底之上持续带大家向前奋进，一举击破物理内存治理的常识盲区，使大家可能鸟瞰整个 Linux 内存管理子系统的整体全貌。 而在正式开始物理内存治理的主题之前，笔者感觉有必须在带大家回顾下上篇文章中介绍的虚拟内存治理的相干常识，不便大家来回比照虚拟内存和物理内存，从而能够全面整体地把握 Linux 内存管理子系统。 在上篇文章的一开始，笔者首先为大家展示了咱们应用程序频繁接触到的虚拟内存地址，清晰地为大家介绍了到底什么是虚拟内存地址，以及虚拟内存地址别离在 32 位零碎和 64 位零碎中的具体表现形式： 在咱们分明了虚拟内存地址这个基本概念之后，随后笔者又抛出了一个问题：为什么咱们要通过虚拟内存地址拜访内存而不是间接通过物理地址拜访？ 原来是在多过程零碎中间接操作物理内存地址的话，咱们须要准确地晓得每一个变量的地位都被安顿在了哪里，而且还要留神以后过程在和多个过程同时运行的时候，不能共用同一个地址，否则就会造成地址抵触。 而虚拟内存空间的引入正是为了解决多过程地址抵触的问题，使得过程与过程之间的虚拟内存地址空间互相隔离，互不烦扰。每个过程都认为本人独占所有内存空间，将多过程之间的协同相干细节通通交给内核中的内存治理模块来解决，极大地解放了程序员的心智累赘。这一切都是因为虚拟内存可能为过程提供内存地址空间隔离的功绩。 在咱们分明了虚拟内存空间引入的意义之后，笔者紧接着为大家介绍了过程用户态虚拟内存空间别离在 32 位机器和 64 位机器上的布局状况： 在理解了用户态虚拟内存空间的布局之后，紧接着咱们又介绍了 Linux 内核如何对用户态虚拟内存空间进行治理以及相应的治理数据结构： 在介绍完用户态虚拟内存空间的布局以及治理之后，咱们随后又介绍了内核态虚拟内存空间的布局状况，并联合之前介绍的用户态虚拟内存空间，失去了 Linux 虚拟内存空间别离在 32 位和 64 位零碎中的整体布局状况： 在虚拟内存全副介绍结束之后，为了可能承前启后，于是笔者持续在上篇文章的最初一个大节从计算机组成原理的角度介绍了物理内存的物理组织构造，不便让大家了解到底什么是真正的物理内存 ？物理内存地址到底是什么 ？由此为本文的主题 —— 物理内存的治理 ，埋下伏笔~~~ 最初笔者介绍了 CPU 如何通过物理内存地址向物理内存读写数据的残缺过程： 在咱们回顾完上篇文章介绍的用户态和内核态虚拟内存空间的治理，以及物理内存在计算机中的实在组成构造之后，上面笔者就来正式地为大家介绍本文的主题 —— Linux 内核如何对物理内存进行治理 2. 从 CPU 角度看物理内存模型在前边的文章中，笔者曾多次提到内核是以页为根本单位对物理内存进行治理的，通过将物理内存划分为一页一页的内存块，每页大小为 4K。一页大小的内存块在内核中用 struct page 构造体来进行治理，struct page 中封装了每页内存块的状态信息，比方：组织构造，应用信息，统计信息，以及与其余构造的关联映射信息等。 ...

写在本文开始之前....从本文开始咱们就正式开启了 Linux 内核内存管理子系统源码解析系列，笔者还是会秉承之前系列文章的格调，采纳一步一图的形式先是具体介绍相干原理，在保障大家清晰了解原理的根底上，咱们再来一步一步的解析相干内核源码的实现。有了源码的辅证，这样大家看得也安心，了解起来也释怀，最起码能够证实笔者没有胡编乱造骗大家，哈哈~~ 内存管理子系统堪称是 Linux 内核泛滥子系统中最为简单最为宏大的一个，其中蕴含了泛滥繁冗的概念和原理，通过内存治理这条主线咱们把能够把操作系统的泛滥外围零碎给拎进去，比方：过程管理子系统，网络子系统，文件子系统等。 因为内存管理子系统过于简单宏大，其中波及到的泛滥繁冗的概念又是一环套一环，层层递进。如何把这些繁冗的概念具备层次感地，并且清晰地，给大家梳理出现进去真是一件比拟有难度的事件，因而对于这个问题，笔者在动笔写这个内存治理源码解析系列之前也是思考了很久。 万事开头难，那么到底什么内容适宜作为这个系列的开篇呢 ？笔者还是感觉从大家日常开发工作中接触最多最为相熟的局部开始比拟好，比方：在咱们日常开发中创立的类，调用的函数，在函数中定义的局部变量以及 new 进去的数据容器（Map，List，Set .....等）都须要存储在物理内存中的某个角落。 而咱们在程序中编写业务逻辑代码的时候，往往须要援用这些创立进去的数据结构，并通过这些援用对相干数据结构进行业务解决。 当程序运行起来之后就变成了过程，而这些业务数据结构的援用在过程的视角里全都都是虚拟内存地址，因为过程无论是在用户态还是在内核态可能看到的都是虚拟内存空间，物理内存空间被操作系统所屏蔽过程是看不到的。 过程通过虚拟内存地址拜访这些数据结构的时候，虚拟内存地址会在内存管理子系统中被转换成物理内存地址，通过物理内存地址就能够拜访到真正存储这些数据结构的物理内存了。随后就能够对这块物理内存进行各种业务操作，从而实现业务逻辑。 那么到底什么是虚拟内存地址 ？Linux 内核为啥要引入虚拟内存而不间接应用物理内存 ？虚拟内存空间到底长啥样？内核如何治理虚拟内存？什么又是物理内存地址 ？如何拜访物理内存？本文笔者就来为大家具体一一解答上述几个问题，让咱们马上开始吧~~~~ 1. 到底什么是虚拟内存地址首先人们提出地址这个概念的目标就是用来不便定位事实世界中某一个具体事物的实在地理位置，它是一种用于定位的概念模型。 举一个生存中的例子，比方大家在日常生活中给亲朋好友邮寄一些本地特产时，都会填写收件人地址以及寄件人地址。以及在日常网上购物时，都会在相应电商 APP 中填写本人的播种地址。 随后快递小哥就会依据咱们填写的收货地址找到咱们的实在住所，将咱们网购的商品送达到咱们的手里。 收货地址是用来定位咱们在事实世界中实在住所地理位置的，而事实世界中咱们所在的城市，街道，小区，屋宇都是一砖一瓦，一草一木实在存在的。但收货地址这个概念模型在事实世界中并不实在存在，它只是人们提出的一个虚构概念，通过收货地址这个虚构概念将它和事实世界实在存在的城市，小区，街道的地理位置一一映射起来，这样咱们就能够通过这个虚构概念来找到事实世界中的具体地理位置。 综上所述，收货地址是一个虚拟地址，它是人为定义的，而咱们的城市，小区，街道是实在存在的，他们的地理位置就是物理地址。 比方当初的广东省深圳市在过来叫宝安县，河北省的石家庄过来叫常山，安徽省的合肥过来叫泸州。不论是常山也好，石家庄也好，又或是合肥也好，泸州也罢，这些都是人为定义的名字而已，然而中央还是那个中央，它所在的地理位置是不变的。也就说虚拟地址能够人为的变来变去，然而物理地址永远是不变的。 当初让咱们把视角在切换到计算机的世界，在计算机的世界里内存地址用来定义数据在内存中的存储地位的，内存地址也分为虚拟地址和物理地址。而虚拟地址也是人为设计的一个概念，类比咱们事实世界中的收货地址，而物理地址则是数据在物理内存中的实在存储地位，类比事实世界中的城市，街道，小区的实在地理位置。 说了这么多，那么到底虚拟内存地址长什么样子呢？ 咱们还是以日常生活中的收货地址为例做出类比，咱们都很相熟收货地址的格局：xx省xx市xx区xx街道xx小区xx室，它是依照地区档次递进的。同样，在计算机世界中的虚拟内存地址也有这样的递进关系。 这里咱们以 Intel Core i7 处理器为例，64 位虚拟地址的格局为：全局页目录项（9位）+ 下层页目录项（9位）+ 两头页目录项（9位）+ 页内偏移（12位）。共 48 位组成的虚拟内存地址。 虚拟内存地址中的全局页目录项就类比咱们日常生活中播种地址里的省，下层页目录项就类比市，中间层页目录项类比区县，页表项类比街道小区，页内偏移类比咱们所在的楼栋和几层几号。 这里大家只须要大体明确虚拟内存地址到底长什么样子，它的格局是什么，可能和日常生活中的收货地址比照了解起来就能够了，至于页目录项，页表项以及页内偏移这些计算机世界中的概念，大家临时先不必管，后续文章中笔者会缓缓给大家解释分明。32 位虚拟地址的格局为：页目录项（10位）+ 页表项（10位） + 页内偏移（12位）。共 32 位组成的虚拟内存地址。 过程虚拟内存空间中的每一个字节都有与其对应的虚拟内存地址，一个虚拟内存地址示意过程虚拟内存空间中的一个特定的字节。2. 为什么要应用虚拟地址拜访内存通过第一大节的介绍，咱们当初明确了计算机世界中的虚拟内存地址的含意及其展示模式。那么大家可能会问了，既然物理内存地址能够间接定位到数据在内存中的存储地位，那为什么咱们不间接应用物理内存地址去拜访内存而是抉择用虚拟内存地址去拜访内存呢？ 在答复大家的这个疑难之前，让咱们先来看下，如果在程序中间接应用物理内存地址会产生什么状况？ 假如当初没有虚拟内存地址，咱们在程序中对内存的操作全都都是应用物理内存地址，在这种状况下，程序员就须要准确的晓得每一个变量在内存中的具体位置，咱们须要手动对物理内存进行布局，明确哪些数据存储在内存的哪些地位，除此之外咱们还须要思考为每个过程到底要调配多少内存？内存缓和的时候该怎么办？如何防止过程与过程之间的地址抵触？等等一系列简单且琐碎的细节。 如果咱们在单过程零碎中比方嵌入式设施上开发应用程序，零碎中只有一个过程，这单个过程独享所有的物理资源包含内存资源。在这种状况下，上述提到的这些间接应用物理内存的问题可能还好解决一些，然而依然具备很高的开发门槛。 然而在古代操作系统中往往反对多个过程，须要解决多过程之间的协同问题，在多过程零碎中间接应用物理内存地址操作内存所带来的上述问题就变得非常复杂了。 这里笔者为大家举一个简略的例子来阐明在多过程零碎中间接应用物理内存地址的复杂性。 比方咱们当初有这样一个简略的 Java 程序。 public static void main(String[] args) throws Exception { string i = args[0]; .......... }在程序代码雷同的状况下，咱们用这份代码同时启动三个 JVM 过程，咱们临时将过程顺次命名为 a , b , c 。 ...

kernel/Documentation/input/uinput.rstIntroductionuinput是一个内核模块，能够从用户空间模仿输出设施。通过写入/dev/uinput（或 /dev/input/uinport）设施，过程能够创立具备特定性能的虚构输出设施。一旦创立了这个虚构设施，过程就能够通过它发送事件，这些事件将传递给用户空间和内核中事件消费者。 Interfacelinux/uinput.huinpu t头定义 ioctl 来创立、设置和销毁虚构设施。 libevdevlibevdev 是 evdev设施的包装库，它提供了创立 uinput设施和发送事件的接口。libevdev比间接拜访uinput 更不容易出错，新软件应该思考应用此形式。 无关 libevdev 的示例和更多信息： https://www.freedesktop.org/s... ExamplesKeyboard events 第一个示例演示了如何创立新的虚构设施，以及如何发送要害事件。为了简略起见，删除了所有默认导入和谬误处理程序。 #include <linux/uinput.h> void emit(int fd, int type, int code, int val) { struct input_event ie; ie.type = type; ie.code = code; ie.value = val; /* timestamp values below are ignored */ ie.time.tv_sec = 0; ie.time.tv_usec = 0; write(fd, &ie, sizeof(ie)); } int main(void) { struct uinput_setup usetup; int fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK); /* * The ioctls below will enable the device that is about to be * created, to pass key events, in this case the space key. */ ioctl(fd, UI_SET_EVBIT, EV_KEY); ioctl(fd, UI_SET_KEYBIT, KEY_SPACE); memset(&usetup, 0, sizeof(usetup)); usetup.id.bustype = BUS_USB; usetup.id.vendor = 0x1234; /* sample vendor */ usetup.id.product = 0x5678; /* sample product */ strcpy(usetup.name, "Example device"); ioctl(fd, UI_DEV_SETUP, &usetup); ioctl(fd, UI_DEV_CREATE); /* * On UI_DEV_CREATE the kernel will create the device node for this * device. We are inserting a pause here so that userspace has time * to detect, initialize the new device, and can start listening to * the event, otherwise it will not notice the event we are about * to send. This pause is only needed in our example code! */ sleep(1); /* Key press, report the event, send key release, and report again */ emit(fd, EV_KEY, KEY_SPACE, 1); emit(fd, EV_SYN, SYN_REPORT, 0); emit(fd, EV_KEY, KEY_SPACE, 0); emit(fd, EV_SYN, SYN_REPORT, 0); /* * Give userspace some time to read the events before we destroy the * device with UI_DEV_DESTROY. */ sleep(1); ioctl(fd, UI_DEV_DESTROY); close(fd); return 0; } Mouse movements ...

Multi-touch Protocolkernel/Documentation/input/multi-touch-protocol.rst :Copyright: |copy| 2009-2010 Henrik Rydberg mailto:rydberg@euromail.se Introduction为了充分利用新的多点触控和多用户设施的全副性能，须要一种形式来上报多个触点（即与设施外表间接接触的对象）具体数据的办法。此文档形容了容许内核驱动程序报告任意数量的触点的详细信息的多点触控(MT)协定。 依据硬件的能力，此协定被分为了两种类型。对于解决匿名触点的设施（type A），此协定形容了如何将所有触点的原始数据发送给接收者。对于可能跟踪可辨认触点的设施（type B），此协定形容了如何通过event slot来发送单个触点的更新信息。 留神： type A多点触控协定曾经过期，所有的内核驱动程序都转用type B协定。 Protcol Usage触点的详细信息被作为独自的ABS_MT事件数据包程序发送，并且只有 ABS_MT 事件被辨认为触点数据包的一部分。 因为以后的单点触控 (ST) 应用程序疏忽了这些事件，因而能够在现有驱动程序中的 ST 协定之上实现 MT 协定。 type A设施的驱动程序通过在每个数据包的结尾调用input_mt_sync()来分隔触点数据包。这样会产生一个SYN_MT_REPORT事件来批示接管方接管以后触点的数据并筹备好接管下一个触点的数据。 type B设施通过在每个数据包的结尾调用input_mt_slot()，并以slot作为参数来分隔触点数据包。这样会产生一个ABS_MT_SLOT事件来批示接管方筹备更新给定的slot的信息。 所有的驱动程序都通过调用input_sync()函数来标记多点触控数据传输的完结。这批示接受者对上一次EV_SYN/SYN_REPORT事件当前的事件进行解决，并筹备好接管新的事件或者数据包。 无状态type A以及有状态type B的次要区别在于应用可辨认的触点来缩小发送到用户空间的数据。slot协定须要应用ABS_MT_TRACKING_ID,它由硬件提供或者通过原始数据计算得出。 对于type A类设施，驱动程序应该生成以后触屏上全副匿名触点的任意枚举。数据包在事件流中呈现的程序并不重要，事件过滤以及手指跟踪被留到了用户空间。 对于type B设施，驱动程序应该将每个可辨认的触点和一个slot关联，并用slot来更新触点的变动。通过批改触点关联的slot的ABS_MT_TRACKING_ID来创立，替换或者销毁触点。非负的ID被认为是无效的触点，-1示意未被应用的slot。 以前没有呈现的ID被认为是新的，不再呈现的ID被认为是曾经移出了的。因为只有扭转了的货色会被发送，因而每个触点的残缺状态必须驻留在接收端。 收到 MT 事件后，只需更新以后slot的相干的属性。 一些设施辨认和(或)跟踪的触点数量超过了它们能够向驱动程序报告的数量。此类设施的驱动程序应将一个 B 型slot与硬件报告的每个触点相关联。每当与slot关联的触点产生更改时，驱动程序应通过更改其ABS_MT_TRACKING_ID使该slot有效。如果硬件信号表明它正在跟踪的触点数量比以后报告的多，则驱动程序应应用 BTN_TOOL_*TAP 事件来告诉用户空间过后硬件正在跟踪的触点的数量。驱动程序应通过显式的发送相应的BTN_TOOL_*TAP事件并在调用input_mt_report_pointer_emulation()时将use_count设置为false来执行此操作。驱动程序应该只颁布硬件能够报告的尽可能多的slot。通过观察最大反对的 BTN_TOOL_*TAP 事件大于在 ABS_MT_SLOT 轴的 absinfo 中报告的 B 类slot的总数，用户空间能检测到驱动程序能够报告比插槽更多的总触点数。 ABS_MT_SLOT轴的最小值必须为0。 Protocol Example A：以下是type A设施双触点触摸的最小事件序列： ABS_MT_POSITION_X x[0] ABS_MT_POSITION_Y y[0] SYN_MT_REPORT ABS_MT_POSITION_X x[1] ABS_MT_POSITION_Y y[1] SYN_MT_REPORT SYN_REPORT挪动其中一个触点后的序列看起来完全相同;所有以后触点的原始数据在每次应用SYN_REPORT同步之间发送。 ...

1.首先找到容器iddocker ps | grep pod名称 2.依据id找到容器PID（容器的实质是过程）docker inspect 容器id | grep Pid 3.进入容器过程的网络命名空间nsenter -t 容器PID -n bash 此时曾经处于容器的网络命名空间中了，验证一下ifconfig后会显示容器中的网络设备咱们的文件系统还是处于宿主机中，能够调用宿主机的工具，并且保留文件在宿主机的文件系统中

排查命令# 查看网卡队列数ls /sys/class/net/网络设备名/queues/ | grep rx | wc -l# 查看CPU每秒解决中断速率mpstat -I SUM -P ALL 3# 查看网卡中断绑核状况cat /proc/interrupts | grep 网络设备名# 查看RPS开启状况cat /sys/class/net/eth*/queues/rx-*/rps_cpus# 查看RFS开启状况cat /proc/sys/net/core/rps_sock_flow_entriescat /sys/class/net/eth*/queues/rx-*/rps_flow_cnt

目录： 为何有本文什么是动静 CPU 频率 什么是 p-stateLinux CPU 性能伸缩(CPU performance scaling) CPUFreq Policy(CPU 频率缩放策略)CPUFreq Policy 的 sysfs 文件接口 policy 通用属性通用的 Scaling Governor performance - Scaling Governorpowersave - Scaling Governor非 Intel CPU 的 Frequency Boost Support 非 Intel CPU 的 boost 的 sysfs 文件接口Intel CPU 的 Scaling Driver 操作模式 (Operation Modes) Active Mode Active Mode 且开启 HWP HWP + performanceHWP + powersaveActive Mode 且禁用 HWPPassive ModeTurbo P-states Support sysfs 中的 no_turbo 属性intel_pstate 的 sysfs 配置Global Attributes实时监控 CPU 理论频率 ...

struct task_struct有struct task_io_accounting ioac; struct task_io_accounting {#ifdef CONFIG_TASK_XACCT /* bytes read */ u64 rchar; /* bytes written */ u64 wchar; /* # of read syscalls */ u64 syscr; /* # of write syscalls */ u64 syscw;#endif /* CONFIG_TASK_XACCT */#ifdef CONFIG_TASK_IO_ACCOUNTING /* * The number of bytes which this task has caused to be read from * storage. */ u64 read_bytes; /* * The number of bytes which this task has caused, or shall cause to be * written to disk. */ u64 write_bytes; /* * A task can cause "negative" IO too. If this task truncates some * dirty pagecache, some IO which another task has been accounted for * (in its write_bytes) will not be happening. We _could_ just * subtract that from the truncating task's write_bytes, but there is * information loss in doing that. */ u64 cancelled_write_bytes;#endif /* CONFIG_TASK_IO_ACCOUNTING */};每个task_struct内嵌的write_bytes，统计是该过程写内存的字节数，这个写的，以后时刻可能还在内存外面，不肯定写到磁盘里了。 ...

scsi_alloc_sgtables函数剖析 struct scatterlist { unsigned long page_link; unsigned int offset; unsigned int length; dma_addr_t dma_address;#ifdef CONFIG_NEED_SG_DMA_LENGTH unsigned int dma_length;#endif};示意的是sg entry在内存中的地址和长度。page_link的作用：依据page_link的bit0和bit1的具体值（bit0 sg是否是链， bit1 sg是否是最初一个）。两种作用复用，一是示意sg entry指向的内存页page构造体，二是对于链起来的sg list，示意sg_table指向的下一个sg_table。一个内存页里，对应sg_table外面的各sg_entry是内存地址间断的（数组），如果sg list超过一个内存页，就得链起来。 /* * Notes on SG table design. * * We use the unsigned long page_link field in the scatterlist struct to place * the page pointer AND encode information about the sg table as well. The two * lower bits are reserved for this information. * * If bit 0 is set, then the page_link contains a pointer to the next sg * table list. Otherwise the next entry is at sg + 1. * * If bit 1 is set, then this sg entry is the last element in a list. * * See sg_next(). * */#define SG_CHAIN 0x01UL#define SG_END 0x02UL/* * We overload the LSB of the page pointer to indicate whether it's * a valid sg entry, or whether it points to the start of a new scatterlist. * Those low bits are there for everyone! (thanks mason :-) */#define sg_is_chain(sg) ((sg)->page_link & SG_CHAIN)#define sg_is_last(sg) ((sg)->page_link & SG_END)#define sg_chain_ptr(sg) \ ((struct scatterlist *) ((sg)->page_link & ~(SG_CHAIN | SG_END)))数组的sg_table: ...

The integrity metadata (or protection information in SCSI terminology) includes a checksum for each sector as well as an incrementing counter that ensures the individual sectors are written in the right order.完整性元数据包含每个扇区的校验和及减少的用来确保每个扇区正确的写入程序的计数。 The SCSI Data Integrity Field works by appending 8 bytes of protection information to each sector. The data + integrity metadata is stored in 520 byte sectors on disk. Data + IMD are interleaved when transferred between the controller and target. The T13 proposal is similar.scsi的数据完整性字段，通过附加8字节的爱护信息到每个扇区来工作。数据和完整性元数据被贮存在磁盘上的520字节的扇区。在控制器和器件之间传输时，数据和完整性元数据被穿插读取。T13提案也相似。 ...

https://mirrors.tuna.tsinghua...

微信公众号：奔跑吧Linux社区欢送订阅笨叔旗舰篇视频节目：https://weidian.com/?userid=1... 第二季更新视频啦明天咱们更新了两集第二季的视频节目，这两集视频节目都是和过程调度治理相干的代码剖析视频，咱们是基于Linux 5.0来解说代码的哟，没错，咱们视频是率领大家间接鲁5.0代码。咱们会在第一季+第二季旗舰篇视频里陆续更新Linux 5.0内核的代码剖析视频，不见不散！ 过程代码剖析6 - 再谈SMP负载平衡用4维空间的角度来解说过程的负载 下面这个视频只是咱们这一期视频的一个预览片，全程1个多小时，有趣味的小伙伴能够点击浏览原文，进入笨叔微店订阅旗舰篇视频课程。咱们在上2个月和大家录制了两期的SMP负载平衡的代码剖析视频，那咱们这期节目还是持续和大家聊负载平衡，一方面是负载平衡 是过程治理里最简单的模块，波及的概念和代码量也比拟多，笨叔怕大家一时半会还没有齐全了解，所以咱们这期视频还是持续来聊负载平衡。 咱们在第一次smp负载平衡节目里，次要是和大家聊负载是怎么计算的，这个很重要，外面波及到很多公式和概念。这一期视频节目没看明确，前面的代码看起来也是十分吃力的。那我呢，在最近奔跑吧第二版订正过程中，对一些概念，从新做了一些订正，所以，这期视频，我会更新一下咱们最近对负载计算的思考，和我本人定义的一些新概念，不过，公式啥的，基本上都没变动，只是概念做了一些优化，次要是 怎么用中文，更好的形象和了解这些 公式和代码，咱们会4维空间的角度来解说负载这个概念。 第二次smp负载平衡节目里，咱们次要是讲 调度域和调度组的关系，这个也是很重要的，因为代码里如何去找一个闲暇的CPU和一个忙碌的CPU，这不是乱找的，是有法则的，这个法则就是遵循调度域和调度组的层次结构来，咱们稍后在和大家简略回顾一下。 咱们来扯一下物理学的4维空间。咱们晓得0维空间是点，一维空间是直线，两个点连起来就是一根直线。两条平行的线是不会相交的。两条不平行的线，他们有可能会在某个点相交。如果一个生命是在一条直线上，那么它就无奈和另外一条平行的直线上的生命相遇。那什么是二维空间呢，二维空间是几根线连起来的面，二维空间只有长和宽。而三维空间是啥呢，把立体卷起来，造成了一个三维的空间。三维空间是有长宽高，从而造成一个三维的，平面的空间。所以，三维空间能够了解为有有数的立体组成。比方，一个最强大脑里 常常常常玩的魔方，它就有好几个面组成了一个正方体。 那什么是4维空间，它们在工夫这个维度由很多的三维空间组成，所以4维空间多了工夫这个概念。咱们生存的4维空间是由无数个静止的三维空间 间断地，动静地，变动而成形成的。咱们就生存在这个动静的三维空间里。如果咱们把 工夫用宏观来看，你能够把它看成是由无数个宏观的三维空间组成的一个时间轴。其实，咱们人啊，是生存的4维空间里，你能看到三维的空间，你能感触到工夫的一分一秒的变动。咱们在时间轴是间断地匀速的变动，它不能减速，不能加速，不能静止，咱们人类无法控制这条工夫线。 还有的人说，人是生存在5维空间里，当人来到了地球，就去了五维空间了。 其实，咱们生存很多货色都是4维空间的，比如说，100块钱的一张纸币，它是一个动态的货色，你能够把它看成是一个3维空间外面的一个物体，它是静止的。然而呢，如果咱们把工夫思考进去，10年后，这个100块的购买力 就不是100块了，当初100块，你可能能够买30斤大米，3块3一斤大米，10年后可能只能买10斤大米了，这就是4维空间。它随着工夫的变动而变动的。扯蛋扯远了。咱们回到方才的问题，咱们发现间接使用权重，没有思考4维空间的影响，它只是停留在3维空间里，那当然是不准了，咱们现实生活是4维空间，必须把第4维空间，工夫这个因素思考进去。 Linux内核里应用了decay_avg_load的计算公式，为什么这里要应用decay这个货色呢？decay这个单词是衰减的意思。咱们还是从4维空间的角度来看。一个能量在时间轴里，它是会缓缓衰减的。比方咱们收回的声音，它就会随着工夫缓缓衰减，在几十米的中央基本上听不见了。在举个例子，方才提到的人民币购买力的状况，其实也是经济学上一种衰减，这个随着工夫的衰减是合乎经济法则的。比方，10几年前，上海一套房子单价才3~4千一平方米，当初基本上要涨到5~6，7~8w一平方米了，这阐明同样的一百块钱 随着时间推移，购买力的降落，这叫做通货膨胀。很多人在通过买房子或者投资股票来抵制通胀。很多人感觉一线城市的房子能够抵制通胀，然而很难了解股票为什么能抵制通胀，其实情理很简略，一个国家的GDP是由这个国家所有的公司来奉献的，那么那些好公司的业绩肯定是优于整个国家的GDP，GDP其实是一个平均值，所有公司的平均值。比方咱们当初GDP增长6~7%，那些头部的优质公司，它们的年增长率肯定大于6~7%，对吧。咱们在股市大跌或者低迷的时候，买入头部优质的公司长期持有，它们的业绩增长肯定是远远大于GDP，也大于M2的速度，这样就能够达到抵制通胀的目标，很多人没有把这个简略的4维空间的道现实明确，而是盯着k线图这个二维空间的图形来钻研股市，而后想着明天买今天卖，那当然是被割韭菜了。 过程代码导读7 - 实时性介绍和剖析很多人可能对实时性的概念有点含糊，什么是实时性？实时性是不是就是让零碎跑的更快的意思？是不是跑分更多？什么是硬实时？什么是软实时？Linux内核在关上了内核抢占性能之后，要达到硬实时规范，还有什么坎？咱们在视频里详细分析，实时性有哪些延时？产生延时的可能的起因是什么？ 欢送订阅奔跑吧旗舰篇视频课程笨叔会持续录制基于Linux 5.0的代码剖析的视频课程，有趣味的同学能够微店或者淘宝店订阅笨叔的第一季+第二季旗舰篇视频，旗舰篇视频是继续不断更新的！一次订阅，继续更新！点击浏览原文，进入笨叔微店订阅旗舰篇视频课程。 蓝色奔跑吧第二版曾经交稿笨叔历时1年新订正的蓝色奔跑吧曾经交稿，第二版会新增很多新内容，而且大部分内容是从新重构的，第二版齐全基于Linux5.0 + ARM64/x86_64来编写的。书稿在3月初曾经交稿，请大家急躁期待。想看Linux 5.0的代码解说，能够订阅旗舰篇视频课程，笨叔会在视频里具体和大家剖析5.0代码的实现。 第二版具体目录请登录“奔跑吧linux社区”微信公众号，输出“奔跑吧第二版”索取。 全新的一套奔跑卷题目，有趣味同学能够登录“奔跑吧linux社区”微信公众号，输出“奔跑卷”索取。 本书预计2020年隆冬出版，到时候笨叔约大家吃西瓜，看奔跑吧！

自从笨叔去年去美帝出差，被共事忽悠花了9000大洋买了一个MAC BOOK，传说美帝买MAC便宜，特地是俄勒冈州免税，再加上敌人的工卡能够打折，笨叔就这么上钩了 本认为MAC用起来很爽。然而，当笨叔装上MS Office之后，发现没有visio，傻眼了！该死的微软，为啥不给MAC开发一个visio！笨叔很土，平时写文档和写书稿都是用word，而后用visio画图，它们俩能够无缝对接。那MAC对笨叔来说就是一个玩具了。 听其余小伙伴说，在MAC上能够用draw.io来画图，而且draw.io有MAC本地装置软件包。 笨叔用draw.io画了一个简略图，试试。 画图的过程和visio差不多，很简略。可是怎么把图嵌入到word呢？傻眼了，总不能导出png图片再插入到word吧，那样图片会失真很多，有没有方法通过矢量图形式插入呢？ 在draw.io官网上看到有word的插件。关上word，在插入页中关上利用商店。 搜寻draw，就能够找到draw.io插件。 关上draw.io插件。 抉择pick device file，就能够导入draw.io文件到word。 导入之后，发现图片是矢量图。 完满！笨叔感觉能够满足写书稿的需要。特地像笨叔这种又土又笨的人，到当初还用word，被用markdown的小伙伴鄙视了一把， 好消息：最新版本试验领导手册曾经悄悄的上线了 下载办法：在“奔跑吧linux社区”微信公众号里输出“试验领导手册”即可！

文/龙蜥社区内核开发人员 陈善佩、吴一昊、邓二伟 Plugsched 是 Linux 内核调度器子系统热降级的 SDK，它能够实现在不重启零碎、利用的状况下动静替换调度器子系统，毫秒级 downtime。Plugsched 能够对生产环境中的内核调度个性动静地进行增、删、改，以满足不同场景或利用的需要，且反对回滚。 基于 plugsched 实现的调度器热降级，不批改现有内核代码，就能取得较好的可批改能力，人造反对线上的老内核版本。如果提前在内核调度器代码的要害数据结构中退出 Reserve 字段，能够额定取得批改数据结构的能力，进一步晋升可批改能力。 Plugsched 开源链接：https://gitee.com/anolis/plug... 那么 Plugsched 诞生的背景或者想要解决的问题是什么？咱们认为有以下 4 点： 利用场景不同，最佳调度策略不同。 利用品种极大丰富，利用特色也是变幻无穷 （throughput-oriented workloads, s-scale latency critical workloads, soft real-time, and energy efficiency requirements），使得调度策略的优化比较复杂，不存在“一劳永逸”的策略。因而，容许用户定制调度器满足不同的场景是必要的。调度器迭代慢。 Linux 内核通过很多年的更新迭代，代码变得越来越沉重。调度器是内核最外围的子系统之一，它的结构复杂，与其它子系统严密耦合，这使得开发和调试变得越发艰难。此外，Linux 很少减少新的调度类，尤其是不太可能承受非通用或场景针对型的调度器，上游社区在调度畛域发展缓慢。内核降级艰难。调度器内嵌 （built-in）在内核中，上线调度器的优化或新个性须要降级内核版本。内核公布周期通常是数月之久，这将导致新的调度器无奈及时利用在生产零碎中。再者，要在集群范畴降级新内核，波及业务迁徙和停机降级，对业务方来说代价低廉。无奈降级子系统。kpatch 和 livepatch 是函数粒度的热降级计划，可批改能力较弱，不能实现简单的逻辑改变；eBPF 技术在内核网络中广泛应用，但当初调度器还不反对 ebpf hook，未来即便反对，也只是实现部分策略的灵便批改，可批改能力同样较弱。Plugsched 能将调度器子系统从内核中提取进去，以模块的模式对内核调度器进行热降级。通过对调度器模块的批改，可能针对不同业务定制化调度器，而且应用模块可能更麻利的开发新个性和优化点，并且能够在不中断业务的状况下上线。图1 plugsched: 业务不中断 应用 plugsched 具备以下 6 大劣势： 与内核公布解耦：调度器版本与内核版本解耦，不同业务能够应用不同调度策略；建设继续运维能力，减速调度问题修复、策略优化落地；晋升调度畛域翻新空间，放慢调度器技术演进和迭代可批改能力强 ：能够实现简单的调度个性和优化策略，能人之所不能保护简略：不批改内核代码，或大量批改内核代码，放弃内核主线洁净整洁；在内核代码 Tree 外独立保护非通用调度策略，采纳 RPM 的模式公布和上线简略易用：容器化的 SDK 开发环境，一键生成 RPM，开发测试简洁高效向下兼容：反对老内核版本，使得存量业务也能及时享受新技术红利高效的性能：毫秒级 downtime，可疏忽的 overhead。Plugsched 利用案例Plugsched 相比 kpatch 和 livepatch 可批改能力更强，热降级范畴更广，plugsched 是子系统范畴的热降级，而后者是函数级别的热降级。对于 plugsched 而言，无论是 bugfix，还是性能优化，甚至是个性的增、删、改，都可胜任。鉴于 plugsched 较强的可批改能力，它可利用到以下场景： ...

我采纳的零碎是 Ubuntu20.04，内核版本为 5.10.56，体系结构为 x86_64。 增加零碎调用是在内核源码树中操作，所有版本的内核源代码都能够在Linux内核官方网站中找到，能够去自行下载。 1. 注册零碎调用号在 Linux 中，每个零碎调用都被赋予了一个零碎调用号。这样，通过这个举世无双的号就能够关联系统调用。当用户空间的过程执行一个零碎调用的时候，这个零碎调用号就用来指明到底是要执行哪个零碎调用；过程不会提及零碎调用的名称。 内核记录了零碎调用表中的所有已注册过的零碎调用的列表，存储在 sys_call_table 中。每一种体系结构中，都明确定义了这个表，在本零碎 x86_64 中，它定义于 arch/x86/entry/syscalls/syscall_64.tbl。 零碎调用表中每一项都以下由四个元素组成： <number> <abi> <name> <entry point> 其中，<num> 代表零碎调用号，例如在 x86_64 架构中 open 的零碎调用号就是 5；<abi> 即 x86_64 架构的 ABI，其含意 application binary interface（应用程序二进制接口）；<name> 是零碎调用的名字；<entry point> 代表零碎调用在内核的接口函数，在 <name> 前加 sys_ 即可。 在零碎调用表中最初一项填入这四个元素即可注册零碎调用。 2. 申明零碎调用函数原型为了保障增加的零碎调用能被找到并且调用，须要在 include/linux/syscalls.h 中申明该零碎调用的函数原型。 每个零碎调用都对应一个内核服务例程来实现该零碎调用的具体性能，其命名格局都是以 sys_ 结尾。这是 Linux 中所有零碎调用都应该恪守的命名规定，例如零碎调用 bar() 在内核中也实现为 sys_bar() 函数。 函数申明中的 asmlinkage 限定词是一个编译指令，用于告诉编译器仅从堆栈中提取该函数的参数，而不是从寄存器中，因为在执行服务例程之前零碎曾经将通过寄存器传递过去的参数值压入内核堆栈了。所有的零碎调用都须要这个限定词。 其次，零碎调用函数返回值类型是 long。为了保障 32 位和 64 位零碎的兼容性，零碎调用在用户空间和内核空间有不同的返回值类型，在用户空间为 int，在内核空间为 long。 ...

从0——1的内核编译当你接触到内核，你在真正的开始意识计算机 每次萌生入手玩内核的想法，但总是因为各式各样的花式借口放弃了，遂打算一点一点的记录下学习内核的过程，并将遇到的问题和大家分享。 如果你也想退出进来！欢送私信我，大家一起玩转内核 ! 为防止出错，我是从最开始的虚拟机开始部署，用的是Linux Ubuntu 20.04.2（最新出炉~~~）。但其实这并不障碍咱们，在任何的Linux零碎上都能够通用的解决内核编译的从0到1。 开整下载内核源码装置依赖解压源码配置内核编译和装置启用内核为疏导Let's Do It下载内核源码官网副品 内核源码下载条传送门： [kernel.org](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/refs/).命令行下载：wget https://git.kernel.org/torval...*.tar.gz（ *** 代表的是你抉择Linux的版本号）正版尽管好，然而国内的下载速度的确是真的慢，换一下清华的源，速度会快很多！ ==换源应该在下载源码前口头== vim /etc/apt/sources.listvim 关上软件源，将原文件做个备份，而后将文件替换为上面内容，应用 TUNA 的软件源镜像。 # 默认正文了源码镜像以进步 apt update 速度，如有须要可自行勾销正文deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal main restricted universe multiverse# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal main restricted universe multiversedeb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-updates main restricted universe multiverse# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-updates main restricted universe multiversedeb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-backports main restricted universe multiverse# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-backports main restricted universe multiversedeb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-security main restricted universe multiverse# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-security main restricted universe multiverse清华的kernel源码shell下载据点： ...

龙蜥社区 SIG 周会会邀请各个 SIG 组核心成员做技术分享。本文整顿自 Cloud Kernel SIG 双周会的分享，当初和大家一起回顾龙蜥内核的 Load Averages。Cloud Kernel SIG 是一款定制优化版的内核产品，在 Cloud Kernel 中实现了若干针对云基础设施和产品而优化的个性和改良性能，旨在进步云端和云下客户的应用体验。与其余 Linux 内核产品相似，Cloud Kernel 实践上能够运行于简直所有常见的 Linux 发行版中。Load Averages 作为一个经典的 Linux 零碎负载监控指标，在服务器数据中心被广泛应用。"龙蜥内核的 Load Averages 分析"系列分享邀请了 Cloud Kernel SIG 负责人庞训磊，深刻分析龙蜥内核的 Load Averages 原理细节，并分享在数据中心集群零碎遇到的各种 Load 抖动问题及心得体会。（现视频回放已上线至龙蜥官网-反对-视频，大家能够上官网查看。）本次直播分为高低两期： 上期：深刻分析了龙蜥内核的 Load 原理及实现，开篇展现了对 Linux Load 的直观意识，追溯 Load 定义的历史和规范由来，从数学原理上具体讲述了它背地的含意。接下来展现了 Linux 内核对 Load 实现的代码细节和挑战，并揭示了规范Linux Load实现的有余，以及龙蜥内核针对这些不足之处所做的自研补充。扫描图中二维码，可中转视频回放。（直播视频回放上）下期：数据中心集群里的 Load 高和随机抖动始终以来是一个困扰运维和零碎工程师的一大难题，本期分享了对于 Load 异样的线上实战心得，从经典计划、用户态计划和内核态计划等多维度进行比照实战，揭开了 Load 高和随机抖动问题的神秘面纱。（直播视频回放下） 对于课件获取形式： 关注公众号【OpenAnolis龙蜥】回复“龙蜥课件”即可收费获取，欢送大家多多浏览，多多交换。 视频回放链接地址： 上期： https://openanolis.cn/video/4... 下期：https://openanolis.cn/video/4...退出Cloud Kernel SIG：欢送更多开发者退出Cloud Kernel SIG： 网址：https://openanolis.cn/sig/Clo... ...

从数据流的角度整顿下安卓平台音频数据从HAL层达到DSP这个流程。 以 MultiMedia22 --> QUIN_TDM_RX_0 播放为例。 次要关注pcm数据写到dsp, 以及将前后端路由信息告知dsp两个点。 <!-- more --> [Platform:高通 8155 gvmq Android 11] [Kernel:msm-5.4] 代码可参考codeaurora 按如下形式下载 repo init -u https://source.codeaurora.org/quic/la/platform/manifest.git -b release -m LA.AU.1.3.2.r2-02600-sa8155_gvmq.0.xml --depth 1repo sync -c kernel/msm-5.4 platform/vendor/opensource/audio-kernel platform/hardware/qcom/audio platform/external/tinyalsa浏览本文最好对ALSA或者ASOC(ALSA System on Chip)有所理解，相干的文档可看下 <<Kernel Didr>>/Documentation/sound/soc/overview.rst及该目录下的文档, 或者网上搜一下有一大堆材料。 简略的说，Linux ASOC架构为了XXX目标，提出了一套这也牛逼那也高级还很省电(DAPM)的音频架构，当然也有全新的玩法和很多术语，从驱动角度来说，有三个局部比拟重要： Codec局部驱动 codec编解码芯片相干，比方其Mixer,管制，DAI接口，A/D,D/A等，这部分要求仅为codec通用局部，不蕴含任何平台或者机器相干代码，以不便运行在任何架构和机器(machine)上。Platform局部驱动 包含音频DMA，数字音频接口（DAI）驱动程序（例如I2S，AC97，PCM）和DSP驱动（高通有的文档把这DSP驱动独自拎进去，等同于CPU驱动），这部分也仅针对soc cpu，不得蕴含特定板级相干代码，也就是说也是机器(machine)无关的。Machine局部驱动 codec和platform都是与机器无关的，它们是绝对独立的两个局部，那谁把他们黏合在一起呢？这个工作就落在了machine上，它形容和绑定(dai link) 这些组件并实例化为声卡，蕴含有codec和platform特定相干代码。它能够解决任何机器特定的管制(GPIO, 中断, clocking, jacks, 电压等)和机器级音频事件（例如，在播放开始时关上speaker/hp放大器）。从数据流的角度来说，有两个概念比拟重要： FE-DAI Front-End DAI, 前端，对用户空间可见，为pcm设施，可通过mixer操作路由到后端，与后端连贯上，可路由到多个后端DAIs。BE-DAI Back-End DAI, 后端，对用户空间不可见，可路由到多个前端DAIs。前端和后端的可路由形式会有个路由表，规定了哪些可式可连上。 提到BE和FE DAI，不得不说的一个概念是 Dynamic PCM, 可看下文档 <<Kernel Didr>>/Documentation/sound/soc/dpcm.rst ，下图也出自该文档， ...

近日，平安钻研人员在 Linux 内核文件系统中发现了一个 size_t-to-int 类型转换破绽，并认为 2014 年以来的所有 Linux 内核版本均有可能受到影响。该破绽被命名为 Sequoia（编号 CVE-2021-33909），是一个权限晋升破绽，可使低权限用户取得 root 权限。 Sequoia 破绽的原理Linux 内核文件系统接口是一个层级架构，包含用户接口层、文件系统实现和存储设备驱动程序，是操作系统最重要的性能，在大多数 Linux 操作系统中极为广泛。 Linux 内核的 seq_file 接口产生蕴含记录序列的虚构文件，每个记录必须适宜 seq_file 缓冲区。当空间耗尽时，它只需将其体积翻倍即可扩充空间。然而，如果 size_t 变量被传递给 size 参数为 32 位整数而不是 size_t 的函数时，会产生什么呢？这正是 Sequoia 破绽的攻打原理。 来自 Qualys 的平安钻研人员示意：通过创立、挂载和删除一个总门路长度超过 1GB 的深层目录构造，并 open()s 和 read()s /proc/self/mountinfo，无特权的本地攻击者能够通过一系列其余操作实现内存越界写入。攻击者能够借此毁坏数据，使零碎解体，甚至执行未经受权的代码。 Qualys 钻研人员胜利利用该破绽，在 Ubuntu 20.04、Ubuntu 20.10、Ubuntu 21.04、Debian 11 和 Fedora 34 工作站的默认装置设置下取得了齐全的 root 权限。其余 Linux 发行版也有可能存在该破绽并被利用。 解决方案Qualys 团队于 6 月初发现该破绽，目前红帽曾经公布了补丁。7 月 20 日，Linux 内核维护者 Greg Kroah-Hartman 公布了 Linux 内核 5.13.4 版本针对 Sequoia 的内核补丁。 ...

间隔Linux 内核 5.13 稳定版公布才两周，首个 Linux 内核 5.14 候选版本 (RC) 曾经诞生了。7 月 11 日，Linus Torvalds 公布 Linux 5.14-rc1，其两周的窗口合并期曾经完结。 Linus Torvalds 示意，Linux 5.14-rc1 版本曾经可用于公共测试。该版本包含来自约 1650 名开发人员的大概 13k 个提交，AMD GPU 硬件方面产生了很大变动。此外，该版本删除了遗留的 IDE 代码，当初所有 IDE 反对都基于 libata。 与所有新的内核版本一样，Linux 5.14 将带来驱动更新，以反对更多硬件设施。此外，新版本还有文件系统、架构、网络、调度、虚拟机方面有所改进，当然还有文档和工具更新。 Linux 内核 5.14 的最终版本应该会在八月底或 9 月初公布。像平常一样，这取决于在整个开发周期中有多少候选版本。 想要对该版本进行测试的同学，能够在 kernel.org 网站下载 Linux 5.14-rc1。然而这是一个预公布版本，并不适宜在生产机器上应用。 Linus Torvald 示意，“总的来说，我不认为这个版本带来任何微小惊喜。就规模而言，这仿佛也是很惯例的版本。咱们期待这是一个美妙而平静的公布周期，但将来的事件你无奈意料。” 参考链接： http://lkml.iu.edu/hypermail/...https://9to5linux.com/linus-t...

IP协定 是网络的最重要局部，毫不夸大地说，正是因为有 IP协定 才有了互联网。而 IP协定 最重要的是 IP地址，IP地址 就如同咱们的家庭住址一样，用于其他人不便找到咱们的地位。 当然，这篇文章并不是介绍 IP协定 的原理，无关 IP协定 的原理能够参考经典的书籍《TCP/IP协定详解》，而这篇文章次要介绍的是 Linux 内核怎么实现 IP协定。 IP协定简介尽管咱们不会对 IP协定 做具体介绍，然而还是作个简略的介绍吧，不然间接剖析代码有点唐突。 如果有一台计算机A和一台计算机B，计算机A想与计算机B通信的话怎么办？ 如果计算机A与计算机B是直连的，那么计算机A能够间接发送信息给计算机B，如下图： 所以，如果是直连的话，问题很容易解决。然而，大多数状况下，互联网上的计算机都不是直连的。试想一下，如果在中国的电脑如果要与美国的电脑发送音讯，那是不可能间接通过一条网线连贯的。 那么，互联网上的计算机之间是通过什么连贯的的？答案就是 路由器。如下图： 因为在互联网中，计算机与计算机之间不是直连的，所以两台计算机之间要通信的话不能间接发送音讯，因为不同的计算机之间不晓得对方的地位。 那么，有什么方法解决呢？咱们现实生活中，房子都有一个固定的地址，如：广东省广州市天河区林和西路98号，咱们能够通过这个地址找到对应的房子。所以，对应互联网上的计算机，咱们也能够人为的为其编上地址，名为 IP地址。 IP地址 由一个 32 位的整型数字示意，学过计算机科学的同学都指定，一个 32 位的整型数字可能示意的范畴为：0 ~ 4294967295。所以，IP地址 实践上可能反对 4294967296 台计算机上网（但事实上远远少于这个数，因为有很多地址用于非凡用处）。 然而，32 位的整型数字对人类的记忆不太敌对，所以，又将这个 32 位的整型数字分成 4 个 8 位的整型数字，而后用 点 将他们连接起来，如下图： 所以，IP地址 示意的范畴如下： 0.0.0.0 ~ 255.255.255.255咱们能够在 Windows 零碎的网络设置处查看到本机的 IP地址，如下图： 有了 IP地址 后，就能够为互联网上的每台计算机设置 IP地址，如下图： 这样，为每台计算机设置好 IP地址 后，不同计算机之间就能够通过 IP地址 来进行通信。比方，计算机A想与计算机D通信，那么就能够通过向 IP地址 为 11.11.1.1 的地址发送音讯。 ...

在 Linux 零碎中，调用 fork 零碎调用创立子过程时，并不会把父过程所有占用的内存页复制一份，而是与父过程共用雷同的内存页，而当子过程或者父过程对内存页进行批改时才会进行复制 —— 这就是驰名的 写时复制 机制。 上面咱们将剖析 Linux 写时复制（Copy On Write） 机制的原理。 虚拟内存与物理内存过程的内存可分为 虚拟内存 和 物理内存。 物理内存：就是电脑装置的内存条，如果电脑装置了2GB的内存条，那么零碎就用于 0 ~ 2GB 的物理内存空间。虚拟内存：虚拟内存是应用软件虚构的，在 32 位操作系统中，每个过程都独占 4GB 的虚拟内存空间。应用程序应用的是 虚拟内存，比方 C 语言取地址操作符号 & 所失去的地址就是 虚拟内存地址。而 虚拟内存地址 须要映射到 物理内存地址 能力应用，如果应用没有映射的 虚拟内存地址，将会导致 缺页异样。 虚拟内存地址 映射到 物理内存地址 如下图所示： 如上图所示，过程A与过程B的雷同 虚拟内存地址 映射到不同的 物理内存地址，这就是不同过程的雷同虚拟内存地址互不影响的起因。 写时复制原理后面介绍了 虚拟内存 与 物理内存 的概念，接下来将会介绍 Linux 写时复制 的原理。 后面说过，虚拟内存 须要与 物理内存 进行映射能力应用，如果不同过程的 虚拟内存地址 映射到雷同的 物理内存地址，那么就实现了共享内存的机制。如下图所示： 因为过程A的 虚拟内存M 与过程B的 虚拟内存M' 映射到雷同的 物理内存G，所以当批改过程A 虚拟内存M 的数据时，过程B 虚拟内存M' 的数据也会跟着扭转。 ...

转载：https://www.cnblogs.com/sctb/...1. 编译运行代码从如下链接取得： https://github.com/torvalds/l...编写 Makefile 文件： obj-m += configfs_sample.oall: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modulesclean: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean编译生成内核模块： makels -l -rwxr--r-- 1 abin abin 10K Oct 27 16:58 configfs_sample.c？ -rw-rw-r-- 1 abin abin 13K Oct 29 11:16 configfs_sample.ko -rw-rw-r-- 1 abin abin 603 Oct 29 11:16 configfs_sample.mod.c -rw-rw-r-- 1 abin abin 2.6K Oct 29 11:16 configfs_sample.mod.o -rw-rw-r-- 1 abin abin 12K Oct 29 11:16 configfs_sample.o -rw-rw-r-- 1 abin abin 166 Oct 29 11:16 Makefile -rw-rw-r-- 1 abin abin 92 Oct 29 11:16 modules.order -rw-rw-r-- 1 abin abin 0 Oct 29 11:16 Module.symvers其中，configfs_sample.ko 使编译好的内核模块，应用如下命令加载该模块： ...

转载：https://www.cnblogs.com/sctb/...互联网上的好货色越来越少，且看且珍惜，请尊重版权。 1. 什么是configfs?configfs 是一个基于内存的文件系统，它提供了与sysfs相同的性能。sysfs 是一个基于文件系统的内核对象视图，而configfs 是一个基于文件系统的内核对象管理器（或称为config_items）。 在 sysfs 中，一个对象在内核中被创立（例如，当内核发现一个设施时），并在 sysfs 中注册，而后它的属性会呈现在 sysfs 中，容许用户空间通过 readdir(3)/read(2) 读取，同时，也容许用户通过 write(2) 批改一些属性。很重要的一点，对象是在内核中被创立和销毁的，内核管制着 sysfs 示意内核对象的生命周期，而 sysfs 不能干涉。 configfs 的 config_item 是通过用户空间显式操作 mkdir(2) 创立， rmdir(2) 销毁的。对象的属性在 mkdir(2) 时呈现，并且能够通过 read(2) 和 write(2) 进行读取或批改。和 sysfs 一样，readdir(3) 能够查问 items 和属性的列表，symlink(2) 能够用来将 items 分组。与 sysfs 不同的是，configfs 示意的生命周期齐全由用户空间管制，反对这些 items 的内核模块必须对用户管制做出响应。 sysfs 和 configfs 应该同时存在于一个零碎中，任何一个都不能取代另一个。 2. 应用configfsconfigfs 能够编译为一个模块，也能够编译到内核中。你能够通过以下命令拜访它： sudo mount -t configfs none /sys/kernel/config/除非客户端模块也被加载，否则 configfs 树是空的。这些模块将它们的 item 类型作为子系统注册到 configfs 中，一旦客户端子系统被加载，它将作为一个（或多个）子目录呈现在 /sys/kernel/config/ 下。和 sysfs 一样，无论是否挂载在 /sys/kernel/config/ 上，configfs树始终存在。 ...