1.鸿蒙轻内核M核源码分析：中断Hwi
2.Linux内核源码解析---万字解析从设计模式推演per-cpu实现原理
3.在离线混部-Koordinator Cpu Burst 特性 源码调研
4.-52 原码反码补码
5.一篇讲解CPU性能指标提取及源码分析

鸿蒙轻内核M核源码分析：中断Hwi

       在鸿蒙轻内核源码分析系列中，制cu自制入本文将深入探讨中断模块，源码旨在帮助读者理解中断相关概念、门源码鸿蒙轻内核中断模块的制cu自制入源代码实现。本文所涉及源码基于OpenHarmony LiteOS-M内核，源码读者可通过开源站点 gitee.com/openharmony/k... 获取。门源码仿真授权软件源码

       中断概念介绍

       中断机制允许CPU在特定事件发生时暂停当前执行的制cu自制入任务，转而处理该事件。源码这些事件通常由外部设备触发，门源码通过中断信号通知CPU。制cu自制入中断涉及硬件设备、源码中断控制器和CPU三部分：设备产生中断信号；中断控制器接收信号并发出中断请求给CPU；CPU响应中断，门源码执行中断处理程序。制cu自制入

       中断相关的源码硬件介绍

       硬件层面，中断源分为设备、门源码中断控制器和CPU。设备产生中断信号；中断控制器接收并转发这些信号至CPU；CPU在接收到中断请求后，暂停当前任务，转而执行中断处理程序。

       中断相关的概念

       每个中断信号都附带中断号，用于识别中断源。中断优先级根据事件的重要性和紧迫性进行划分。当设备触发中断后，CPU中断当前任务，执行中断处理程序。中断处理程序由设备特定，且通常以中断向量表中的地址作为入口点。中断向量表按中断号排序，存储中断处理程序的地址。

       鸿蒙轻内核中断源代码

       中断相关的单职业源码声明和定义

       在文件 kernel\arch\arm\cortex-m7\gcc\los_interrupt.c 中定义了结构体、全局变量和内联函数。关键变量 g_intCount 记录当前正在处理的中断数量，内联函数 HalIsIntActive() 用于检查是否正在处理中断。中断向量表在中断初始化过程中设置，用于映射中断号到相应的中断处理程序。

       中断初始化 HalHwiInit()

       系统启动时，在 kernel\src\los_init.c 中初始化中断。HalHwiInit() 函数在 kernel\arch\arm\cortex-m7\gcc\los_interrupt.c 中实现，负责设置中断向量表和优先级组，配置中断源，如系统中断和定时器中断。

       创建中断 HalHwiCreate()

       开发者可通过 HalHwiCreate() 函数注册中断处理程序，传入中断号、优先级和中断模式。函数内部验证参数，设置中断处理程序，最终通过调用 CMSIS 函数完成中断创建。

       删除中断 HalHwiDelete()

       中断删除操作通过 HalHwiDelete() 实现，接收中断号作为参数，调用 CMSIS 函数失能中断，设置默认中断处理程序，完成中断删除。

       中断处理执行入口程序

       默认的中断处理程序 HalHwiDefaultHandler() 仅用于打印中断号后进行死循环。HalInterrupt() 是中断处理执行入口程序的核心，它包含中断数量计数、中断号获取、中断前后的操作以及调用中断处理程序的逻辑。

       开关中断

       开关中断用于控制CPU是否响应外部中断。通过宏 LOS_IntLock() 关闭中断，地图采集源码 LOS_IntRestore() 恢复中断状态， LOS_IntUnLock() 使能中断。这组宏对应汇编函数，使用寄存器 PRIMASK 控制中断状态。

       小结

       本文详细解析了鸿蒙轻内核中断模块的源代码，涵盖了中断概念、初始化、创建、删除以及开关操作。后续文章将带来更多深入技术分享。欢迎在 gitee.com/openharmony/k... 分享学习心得、提出问题或建议。关注、点赞、Star 和 Fork 到个人账户，便于获取更多资源。

Linux内核源码解析---万字解析从设计模式推演per-cpu实现原理

       引子

       在如今的大型服务器中，NUMA架构扮演着关键角色。它允许系统拥有多个物理CPU，不同NUMA节点之间通过QPI通信。虽然硬件连接细节在此不作深入讨论，但需明白每个CPU优先访问本节点内存，当本地内存不足时，可向其他节点申请。从传统的SMP架构转向NUMA架构，主要是为了解决随着CPU数量增多而带来的总线压力问题。

       分配物理内存时，numa_node_id() 方法用于查询当前CPU所在的NUMA节点。频繁的导游系列源码内存申请操作促使Linux内核采用per-cpu实现，将CPU访问的变量复制到每个CPU中，以减少缓存行竞争和False Sharing，类似于Java中的Thread Local。

       分配物理页

       尽管我们不必关注底层实现，buddy system负责分配物理页，关键在于使用了numa_node_id方法。接下来，我们将深入探索整个Linux内核的per-cpu体系。

       numa_node_id源码分析获取数据

       在topology.h中，我们发现使用了raw_cpu_read函数，传入了numa_node参数。接下来，我们来了解numa_node的定义。

       在topology.h中定义了numa_node。我们继续跟踪DECLARE_PER_CPU_SECTION的定义，最终揭示numa_node是一个共享全局变量，类型为int，存储在.data..percpu段中。

       在percpu-defs.h中，numa_node被放置在ELF文件的.data..percpu段中，这些段在运行阶段即为段。接下来，我们返回raw_cpu_read方法。

       在percpu-defs.h中，我们继续跟进__pcpu_size_call_return方法，此方法根据per-cpu变量的大小生成回调函数。对于numa_node的int类型，最终拼接得到的是raw_cpu_read_4方法。

       在percpu.h中，bt网站+源码调用了一般的read方法。在percpu.h中，获取numa_node的绝对地址，并通过raw_cpu_ptr方法。

       在percpu-defs.h中，我们略过验证指针的环节，追踪arch_raw_cpu_ptr方法。接下来，我们来看x架构的实现。

       在percpu.h中，使用汇编获取this_cpu_off的地址，代表此CPU内存副本到".data..percpu"的偏移量。加上numa_node相对于原始内存副本的偏移量，最终通过解引用获得真正内存地址内的值。

       对于其他架构，实现方式相似，通过获取自己CPU的偏移量，最终通过相对偏移得到pcp变量的地址。

       放入数据

       讨论Linux内核启动过程时，我们不得不关注per-cpu的值是如何被放入的。

       在main.c中，我们以x实现为例进行分析。通过setup_percpu.c文件中的代码，我们将node值赋给每个CPU的numa_node地址处。具体计算方法通过early_cpu_to_node实现，此处不作展开。

       在percpu-defs.h中，我们来看看如何获取每个CPU的numa_node地址，最终还是通过简单的偏移获取。需要注意如何获取每个CPU的副本偏移地址。

       在percpu.h中，我们发现一个关键数组__per_cpu_offset，其中保存了每个CPU副本的偏移值，通过CPU的索引来查找。

       接下来，我们来设计PER CPU模块。

       设计一个全面的PER CPU架构，它支持UMA或NUMA架构。我们设计了一个包含NUMA节点的结构体，内部管理所有CPU。为每个CPU创建副本，其中存储所有per-cpu变量。静态数据在编译时放入原始数据段，动态数据在运行时生成。

       最后，我们回到setup_per_cpu_areas方法的分析。在setup_percpu.c中，我们详细探讨了关键方法pcpu_embed_first_chunk。此方法管理group、unit、静态、保留、动态区域。

       通过percpu.c中的关键变量__per_cpu_load和vmlinux.lds.S的链接脚本，我们了解了per-cpu加载时的地址符号。PERCPU_INPUT宏定义了静态原始数据的起始和结束符号。

       接下来，我们关注如何分配per-cpu元数据信息pcpu_alloc_info。percpu.c中的方法执行后，元数据分配如下图所示。

       接着，我们分析pcpu_alloc_alloc_info的方法，完成元数据分配。

       在pcpu_setup_first_chunk方法中，我们看到分配的smap和dmap在后期将通过slab再次分配。

       在main.c的mm_init中，我们关注重点区域，完成map数组的slab分配。

       至此，我们探讨了Linux内核中per-cpu实现的原理，从设计到源码分析，全面展现了这一关键机制在现代服务器架构中的作用。

在离线混部-Koordinator Cpu Burst 特性 源码调研

       在离线混部场景下，Koordinator引入了Cpu Burst特性来优化CPU资源管理。这个特性源自Linux内核的CPU Burst技术，旨在处理突发的CPU使用需求，减少CPU限流带来的影响。cgroups的参数如cpu.share、cpu.cfs_quota_us和cpu.cfs_burst，分别控制了CPU使用率、配额和突发缓冲效果。在Kubernetes中，资源请求（requests.cpu）和限制（limits.cpu）通过这些参数来实现动态调整，以保证容器间公平的CPU分配。

       对于资源调度，Kubernetes的Bandwidth Controller通过时间片限制进程的CPU消耗，针对延迟敏感业务，如抖音视频服务，通过设置合理的CPU limits避免服务质量下降，同时也考虑资源的高效利用。然而，常规的限流策略可能导致容器部署密度降低，因为时间片间隔可能不足以应对突发的CPU需求。CPU Burst技术正是为了解决这个问题，通过收集未使用的CPU资源，允许在突发时使用，从而提高CPU利用率并减少throttled_time。

       在Koordinator的配置中，通过configMap可以调整CPU Burst的百分比，以及在负载过高时的调整策略。例如，当CPU利用率低于阈值时，允许动态扩展cfs_quota，以应对突发的CPU使用。源码中，会根据节点负载状态和Pod的QoS策略来调整每个容器的CPU Burst和cfs_quota。

       总的来说，Cpu Burst特性适用于资源利用率不高且短作业较多的场景，能有效提升核心业务的CPU资源使用效率，同时对相邻容器的影响较小。在某些情况下，结合cpuset的核绑定和NUMA感知调度可以进一步减少CPU竞争。理解并灵活运用这些技术，有助于优化云计算环境中的资源分配和性能管理。

- 原码反码补码

       -=(最高位“1”代表符号负)

       åŽŸç =

       åç =

       è¡¥ç =

       ï¼ˆç¬¦å·ä½ä¸è¦å˜ï¼‰

一篇讲解CPU性能指标提取及源码分析

       这篇报告主要根据CPU性能指标——运行队列长度、调度延迟和平均负载，对系统的性能影响进行简单分析。

       CPU调度程序运行队列中存放的是那些已经准备好运行、正等待可用CPU的轻量级进程。如果准备运行的轻量级进程数超过系统所能处理的上限，运行队列就会很长，运行队列长表明系统负载可能已经饱和。

       代码源于参考资料1中map.c用于获取运行队列长度的部分代码。

       在系统压力测试前后，使用压力测试工具stress-ng，可以看到运行队列长度的明显变化，从3左右变化到了左右。

       压力测试工具stress-ng可以用来进行压力测试，观察系统在压力下的表现，例如运行队列长度、调度延迟、平均负载等性能指标。

       在系统运行队列长度超过虚拟处理器个数的1倍时，需要关注系统性能。当运行队列长度达到虚拟处理器个数的3~4倍或更高时，系统的响应就会非常迟缓。

       解决CPU调用程序运行队列过长的方法主要有两个方面：优化调度算法和增加系统资源。

       所谓调度延迟，是指一个任务具备运行的条件（进入 CPU 的 runqueue），到真正执行（获得 CPU 的执行权）的这段时间。通常使用runqlat工具进行测量。

       在正常情况下使用runqlat工具，可以查看调度延迟分布情况。压力测试后，调度延迟从最大延迟微秒变化到了微秒，可以明显的看到调度延迟的变化。

       平均负载是对CPU负载的评估，其值越高，说明其任务队列越长，处于等待执行的任务越多。在系统压力测试前后，通过查看top命令可以看到1分钟、5分钟、分钟的load average分别从0.、1.、1.变化到了4.、3.、1.。

       总结：当系统运行队列长度、调度延迟和平均负载达到一定值时，需要关注系统性能并进行优化。运行队列长度、调度延迟和平均负载是衡量系统性能的重要指标，通过监控和分析这些指标，可以及时发现和解决问题，提高系统的稳定性和响应速度。