cpu内核

异步与非阻塞听起来似乎是一回事。从实际效果而言，两者都达到了我们并行I/O的目的。但从计算机内核I/O而言，异步/同步和阻塞/非阻塞实际上是两回事。 操作系统内核对于 I/O只有两种方式 ：阻塞与非阻塞。 在调用 阻塞I/O 时，应用程序需要等待I/O完成才返回结果。阻塞I/O的一个特点是调用之后一定要等到系统内核层面完成所有操作后，调用才结束。以读取磁盘上的一段文件为例，系统内核在完成磁盘寻道、读取数据、复制数据到内存中之后，这个调用才结束。阻塞I/O造成CPU等待I/O，CPU的处理能力不能得到充分利用。为了提高性能，内核提供了非阻塞I/O。 非阻塞I/O 调用之后会立即返回。返回之后，CPU的时间片可以用来处理其他事务，此时的性能提升是明显的。 但非阻塞I/O也存在一些问题，用于完整的I/O并没有完成，立即返回的并不是业务层期望的数据，而仅仅是当前调用的状态。为了获取完整的数据，应用程序需要重复调用I/O操作来确认是否完成。这种重复调用判断操作是否完成的技术叫做 轮询 。 任意技术都并非完美的。阻塞I/O造成CPU等待，非阻塞I/O带来的麻烦却是需要轮询去确认是否完全完成数据获取，它会让CPU处理状态判断，这是对CPU资源的浪费。 下面完美看看轮询技术是如何演进以减小I/O状态判断的CPU损耗。 现存的轮询技术主要有一下几种： 1. read： 最原始性能最低的一种

1.CPU信息查看配置文件/proc/cpuinfo 总核数 = 物理CPU个数 × 每颗物理CPU的核数 总逻辑CPU数 = 物理CPU个数 ×每颗物理CPU的核数 × 超线程数 (1)物理cpu数：主板上实际插入的cpu数量，可以数不重复的 physical id 有几个 grep 'physical id' /proc/cpuinfo | sort -u |wc -l 或 grep 'physical id' /proc/cpuinfo | sort | uniq |wc -l [root@xxx ~]# grep 'physical id' /proc/cpuinfo | sort | uniq physical id : 0 [root@xxx ~]# grep 'physical id' /proc/cpuinfo | sort -u | wc -l 1 [root@xxx ~]# (2)cpu核数：单块CPU上面能处理数据的芯片组的数量，如双核、四核等 grep 'cores' /proc/cpuinfo |uniq [root@xxx ~]# grep 'cores' /proc/cpuinfo |uniq cpu cores : 4 [root@xxx ~]# (3)逻辑cpu数：简单来说，如果超线程数是2，可以使处理器中的1颗内核

在看libvirt如何获取虚拟机的cpu占用率这个问题。计算cpu占用率不可避免的需要直到jiffies的概念。 jiffies是内核中的一个全局变量，用来记录自系统启动一来产生的节拍数。简单描述，就是1s内，内核发起的时钟中断次数。kernel中就使用这个来对程序的运行时间进行统计。这个值实在编译内核时进行设置的。一般有100，250，1000。CONFIG_HZ这个参数就是用来设置1s中的中断次数的。 查看 /proc/stat 可以看到kernel对cpu使用的各项时间进行的统计。 cat /proc/statcpu 1776 10 9610 35061503 4272 0 122 0 0 0cpu0 359 0 1820 8767364 1812 0 40 0 0 0cpu1 398 0 1578 8764789 688 0 18 0 0 0cpu2 593 3 1646 8768085 1076 0 8 0 0 0cpu3 425 6 4564 8761263 694 0 56 0 0 0 cpu的使用率一般包含 user ( 1776 ) 从系统启动开始累计到当前时刻，处于用户态的运行时间，不包含 nice值为负进程。 nice (10) 从系统启动开始累计到当前时刻，nice值为负的进程所占用的CPU时间 system (35061503)

1 目的：实现intel core 2 duo cpu的温度检测 2 分析： 对于intel处理器，每个处理器核心有Digital Thermal Sensors(DTS 数字敏感传感器),该数字传感器的检测值不依赖于外围电路，仅仅取决于 cpu核心的热度，其取值存储于cpu上的一个特殊寄存器中，该寄存器称为Model Specific Register 0x19c(MSR),可以通过rdmsr指令读取，内核代码coretemp.c文件实现了该文件的读取，插入coretemp.ko模块后，可以通过/sys/devices/platform/coretemp.0/目录下的temp1_input、temp2_input等文件读取，温度值基本与lm-sensors读取值一致（lm-sensors基于该内核驱动模块实现的）。 3 hwmon/coretemp.c文件导读， 注：该检测文件的对应文档信息在/documation/hdware/coretemp文件下 3.1 前期工作 对于intel core 2 duo cpu而言，coretemp.c中包含特定架构的头文件为x86/include/asm/process.h 在process.h中定义了cpu_data数据结构： 1 DECLARE_PER_CPU(struct cpuinfo_x86, cpu_info); 2

CPU的两种工作状态：内核态和用户态（或者称管态和目态） 内核态 系统中既有操作系统的程序，也由普通用户的程序。为了安全和稳定性操作系统的程序不能随便访问,这就是内核态 内核态可以使用所有的硬件资源 用户态 不能直接使用系统资源，也不能改变CPU的工作状态，并且只能访问这个用户程序自己的存储空间 用户态和内核态 特权级 Linux使用了Ring3级别运行用户态,Ring0标识内核态 Ring0作为内核态，没有使用Ring1和Ring2。 Ring3状态不能访问Ring0的地址 空间，包括代码和数据。 Linux进程的4GB地址空间，3G-4G部分大家是共享的，是内核态的地址空间，这里存放在整个内核的代码和所有的内核模块， 以及内核所维护的数据。用户运行一个程序，该程序所创建的进程开始是运行在用户态的，如果要执行文件操作，网络数据发送等操作，必须通过 write，send等系统调用，这些系统调用会调用内核中的代码来完成操作，这时，必须切换到Ring0，然后进入3GB-4GB中的内核地址空间去执 行这些代码完成操作，完成后，切换回Ring3，回到用户态。这样，用户态的程序就不能随意操作内核地址空间，具有一定的安全保护作用。 用户态和内核态的转换 系统调用 这 是用户态进程主动要求切换到内核态的一种方式，用户态进程通过系统调用申请使 用操作系统提供的服务程序完成工作

1.CPU移植要求： 1 ） 处理器有对应的能产生可重入代码的 C 编译器 2 ） 处理器支持中断且能提供周期性的中断（通常介于 10 到 1000Hz 之 间）。 3 ） 可以关中断和开中断 4 ） 处理器支持存储和载入堆栈指针、 CPU 寄存器、堆栈的指令。 5 ） 处理器有足够的 RAM 用于存放 uC/OS-III 的变量、 结构体、 内部 任务堆栈、任务堆栈等 6 ） 编译器支持 64 位的数据类型 2. uC/OS-III 的架构和它与其他软件、硬件成分的关系： （ 1 ）移植 uC/OS-III 需修改 3 个与内核相关的文件： OS_CPU.H 、 OS_CPU_A.ASM 、 OS_CPU_C.C 。 （ 2 ）移植 uC/OS-III 需修改 3 个与 CPU 相关的文件： CPU.H 、 CPU_A.ASM 、 CPU_CORE.C 。 （ 3 ） BSP 中通常包含了 uC/OS-III 与定时器（产生时基的定时 器 ）、中断控制器的接口。 （ 4 ） 有些半导体厂商会提高相应的固件库文件， 这些文件会被 包含在 CPU/MCU 中。 移植包括三方面内容： CPU 、 OS 、 BSP 。 2. uC/CPU 与 CPU 相关的代码决定于 CPU 的架构。 例如， 关中断和开中断、 堆栈的字长， 堆栈的生长方向等等。与 CPU 相关的代码被封装在叫 做 uC

top ： 实时动态地查看系统的整体运行情况，是一个综合了多方信息监测系统性能和运行信息的实用工具。 针对如图学习下： 第一行top：任务队列信息，同 uptime 命令的执行结果一致 top - 17:18:47 up 21 days, 51 min, 4 users, load average: 0.06, 0.03, 0.05 系统时间：17:18:47 运行时间：up 21 days, 51 min, 当前登录用户： 4 users 负载均衡(uptime) load average: 0.06, 0.03, 0.05 average后面的三个数分别是1分钟、5分钟、15分钟的负载情况。 load average数据是每隔5秒钟检查一次活跃的进程数，然后按特定算法计算出的数值。 如果这个数除以逻辑CPU的数量，结果高于5的时候就表明系统在超负荷运转。 第二行Tasks： 任务（进程） Tasks: 393 total, 1 running, 384 sleeping, 8 stopped, 0 zombie 总进程: 393 total, 运行:1 running, 休眠:384 sleeping, 停止: 8 stopped, 僵尸进程: 0 zombie 第三行%Cpu(s)：CPU状态信息 %Cpu(s): 0.1 us, 0.0 sy, 0.0 ni, 99.9

本质上讲，如果一个程序不使用任何库、系统调用，所有代码都是自包含的，它是可以直接在CPU上执行的，有疑问的话可以给我发邮件，我乐意受教。 于是问题就来了，一个用户态的程序在调度到CPU上开始执行，这个程序的指令流是否可以为所欲为。 很明显，这是不可能的，在没有内核的CPU上运行的指令流自己会照顾好自己，它确实可以为所欲为； 但在用户态的程序，如果没有系统调用的话你会发现它没有任何操作硬件的能力(就像不会吃饭的傻孩子) 所有要做点什么涉及硬件，你都能找到设计的很贴心的动态库或系统调用之类。 其实本质上的原理与虚拟化的原理是一样的， 用户态程序受到的限制更多，比如说不可能获得中断，不可能访问外设，仅能访问内核为它建立了映射的那一点点内存。 在此背景下，程序如何做到读取文件、存储数据、显示功能呢？ 本质上，系统调用即syscall(可以简单理解为open()，close()等，但其实是被封装过的)为程序完成了这一切， 当然，操作系统用户态提供的库完成了很多很多工作，但是很抱歉，这些工作都是在用户态完成的， 一切真实的硬件操作(除了程序的那点内存)都是由syscall完成的。 可怜的用户态程序，这也是它的运行要依赖于操作系统的原因(先不考虑指令集差异引起程序跨平台的问题，还说没到那层)。 在之前知识不充足的时候，我有过很奇怪的想法， 程序是分为在用户态和内核态的， 当程序进入内核态以后

CPU没有任务时，认为内核把什么都不做作为一件简单的任务是合理的，但事实却并非如此。在Kernel Recipes 2018，Rafael Wysocki讨论了当CPU没事儿的时候干啥，内核如何处理，在当前阶段存在的问题，以及他最近重做的内核idle loop对非工作中的系统的省电性的提升。 idle loop(在内核的空闲循环，也是空闲任务，空闲也是任务)是Wysocki维护的一个内核子系统，控制CPU在没有任务的时候做的事。为了方便讨论，Wysocki先提出了定义：对于一个CPU就是一个能够从内存取指令并在其他CPU执行指令的同时执行指令的实体。在一个简单的单核单指令流系统，此核即CPU；如果处理器有多个核，那么每个核都是一个CPU。如果每个核都为同步指令expose多个接口，也就是Inter所谓的超线程，那么每一个超线程都是一个CPU。 一个CPU没task运行的时候，就是idle。更精确的说，linux内核的内部调度类，包含特殊的idle类。如果在这些调度类中都没有任务，则CPU被认为是idle，如果硬件没有对此没啥考虑，则CPU就会执行无用的指令直到有任务需要它做。无论如何，这都是浪费电，所以大多数CPU都支持由内核操作进入一些低耗电状态，直到它们需要执行任务。 idle状态的进入或退出不是没有消耗的。进入或退出都需要一些时间，并且耗电较普通状态也会有短暂上升

内核将内核命令行的参数解析为“-‌-”。如果内核不识别参数，也不包含“.”，那么参数会被传递给init：带“=”的参数会被传递给init环境，其他会作为命令行参数传递给init。“ -‌- ”之后的所有内容都作为参数被传递给init。 可以通过两种方式指定模块参数：通过带有模块名称前缀的内核命令行，或通过modprobe，例如： (kernel command line) usbcore.blinkenlights=1 (modprobe command line) modprobe usbcore blinkenlights=1 内置在内核中的模块的参数需要在内核命令行上明确规定。modprobe查看内核命令行（/proc/cmdline）并在加载模块时收集模块参数，因此内核命令行也可用于可加载模块。 参数名称中的连字符（破折号）和下划线相同，因此： log_buf_len=1M print-fatal-signals=1 也可以输入为： log-buf-len=1M print_fatal_signals=1 双引号可用于保护值中的空格，例如： param="spaces in here" CPU列表 一些内核参数将CPU列表作为值，例如isolcpus，nohz_full，irqaffinity，rcu_nocbs。该列表的格式为： <cpu number>,…,<cpu