cpu利用率怎么计算(怎么计算cpu的利用率)
这张纸条有以下内容：
1.为什么需要计算每个线程的CPU利用率？
2.这个如何计算线程的CPU利用率是多少？
3.FreeRTOS线程计算的缺点？如何打破FreeRTOS线程计算模式的时间限制？
4.关键代码介绍。
上次介绍了如何计算整个系统：的CPU利用率
《单片机里面的CPU使用率是什么鬼？》
《实操RT-Thread系统CPU利用率功能添加》
但是，没有引入如何来计算每个线程(任务)的CPU利用率。
为什么要计算线程CPU使用率？
首先要问的是，为什么要计算一个线程的CPU利用率？有什么用？
我们知道系统的CPU利用率集中在整个系统的利用率上，利用率越低，越能及时应对外部情况，整个系统的性能就会越好。
但是，这是从系统整体的角度来考虑的，并不能反映单个线程的执行情况。
举个例子，虽然整体CPU利用率是30%，但是一个线程占25%，一个线程占5%。那么你肯定会奇怪为什么这个线程需要占用这么高的CPU利用率。代码写的有问题吗？代码可以优化吗？
在系统运行的时候，如果你能实时观察每个线程的CPU使用情况，那么你就能知道这个线程平时的CPU使用情况是什么样的，为什么后面会高那么多，那么你就能分析出这个线程可能存在的问题，然后就能有针对性的进行检查。
这对于合作开发项目尤为明显。很多情况下，因为有些线程自己不写代码，所以根本不知道代码执行情况。一旦系统，出现问题，他们可能会互相指责。
在计算一个线程的CPU利用率时，一旦发现线程执行异常，就可以交给负责人去检查。
因此，使用运行系统的项目来计算每个线程(任务)的CPU利用率是非常必要的
就像你的电脑一样，风扇嗡嗡作响(CPU高负荷运行)。如果只有一个系统CPU利用率，发现高达90%，但你根本不知道为什么这么高，只能重启。
一旦有了一个进程的CPU利用率，就检查哪个进程的CPU利用率高，关闭对应的进程就行了。根本不需要重启电脑。
计算如何？的线程CPU使用率
现在让我们看一下如何来计算每个线程的CPU利用率。
从前面的笔记中，我们其实可以猜出如何的计算，无非是得到每个线程的执行时间。
例如，在一秒钟内，如果空闲任务执行700毫秒，任务1执行200毫秒，任务2执行100毫秒，那么每个任务的CPU利用率分别为70%、20%、10%。
过去，在计算系统，软件方法的CPU利用率时，使用的是计算空闲任务的运行时间，这必然是不准确的，所以最好的方法是使用硬件计时。
因为Osprey使用STM32F103进行测试，所以使用DWT外设进行精确计时。但是，麻烦的是DWT外设不能在凯尔软件模拟的情况下工作，所以如果要测试，就必须使用硬件模拟。然而，如果你真的想要凯尔软件模拟，没有替代方案，那就是，你可以使用一个硬件定时器，它不能被按下。
毕竟DWT外设的功能在这里简直就是定时器。
既然我们想得到一个线程的执行时间，那么关键的一点就是我们需要知道操作系统什么时候会切换到某个线程，什么时候会从这个线程中切出来由另一个线程执行。
关键是系统内置的钩子函数上一篇note Osprey介绍了空闲钩子函数，今天我们介绍另一个钩子，任务切换钩子函数。
这个钩子函数的特点是，每当系统需要切换到下一个任务时，它将首先被执行。这个函数一般有两个参数，当前任务和要切换的任务。
只要设置了任务切换的钩子函数，并且有时间戳，计算一个任务的执行时间就没那么难了。
例如，操作系统在12345 ms切换到空闲任务执行，突然一个任务准备执行，于是在12445切换到那个准备好的任务执行，这样我们就可以准确计算出空闲任务的执行时间。
1244512345=100毫秒
换句话说，这次空闲任务执行了100毫秒。
如果我们要计算一个空闲任务在单位时间内的执行时间(比如1秒内)，只需要将每次运行到一个空闲任务的时间累加即可。
例如，在一秒钟内，空闲任务被执行五次，即10，200，100，200，50，累计时间为
0 200 100 200 50=560毫秒
因此，空闲任务的CPU利用率可以计算为56%，系统的CPU利用率可以计算为44%。
是的，我们实际上可以通过线程的CPU利用率方法来计算整个系统的CPU利用率。而且，这种计算方法比前面提到的方法的计算更准确、更科学。
之前的时间戳用于计算，但是时间戳会溢出。那时候，你的时间计算还准确吗？
FreeRTOS线程计算极限？
现在鱼鹰就来说说第三个问题，FreeRTOS线程计算的弊端？如何打破 FreeRTOS 线程计算方式的时间限制？
从网上查找FreeRTOS任务CPU计算相关的资料，可以得到以下信息：
1、需要开一个定时器，这个定时器中断频率是操作系统时钟的十几倍（为了保证计算精度）。
2、一个64 位的变量在定时器自加更新，一旦变量溢出，时间计算就会出现问题。
（相关细节可查看安富莱教程）
第一个问题会导致系统性能下降（中断频率太高，一般是微秒级别的），而第二个问题导致在一段时间内（小时级别）线程CPU使用率计算准确，超出时间后，计算会有问题，所以教程中不建议在正式版本加入此功能。
第一个问题其实很好解决，就是使用硬件定时器，不再由CPU去更新时间，这样不会占用CPU时间，第二个问题其实也非常好解决，就是通过《延时功能进化论》的方式解决溢出问题，这里不再展开说其中的奥妙。
任务切换钩子函数的实现
总之，鱼鹰接下来的实现方式解决了以上两个痛点，即使无限执行下去，也不会影响到计算精度问题，唯一对系统产生的一点影响，只有在任务切换时消耗的一点计算时间（微秒级别）。
那么先上任务切换钩子函数关键实现代码（RT-Thread）：
如何将这个函数注册到操作系统中被系统调用呢？
通过这个函数即可：
那么现在来分析这个钩子函数实现：
一个静态变量，用于记录切换时的时间戳。
每次任务开始切换时，更新这个时间戳，同时累积时间，这个时间保存在当前任务的user_data里面。
难理解？看下图就清楚了。
假设系统调度是从任务1切换到任务2，即from为任务1，to为任务2，此时获取的时间戳为 T1。
上一次的时间戳我们已经通过静态变量保留了，这里为T0，那么T1-T0就是from任务即任务1在本次运行的时间，只要下次运行任务1时继续不断的累积这个时间，那么就可以得到任务1的总运行时间。
任务2同理。
当然我们不可能一直累积下去，不然肯定会溢出，所以隔一段时间就需要清零，这个时间其实就是线程CPU计算的周期。
这里还有一个函数没有说，就是 get_curr_time()，在这里使用DWT，为了可以重新实现该函数，鱼鹰使用了弱属性 weak（关于这个看参考：《》）。
这里可以看到有个注释，不要使用 rt_tick_get 函数，为啥？
精度太低，有些任务本来执行了的，但是因为执行时间小于操作系统的时钟（比如1毫秒），那么就无法累积时间了，那么即使这个任务运行再多，时间累积也为 0，这肯定是我们不希望看到的。
然后再说一个点，为了简化代码（钩子函数代码只有短短几行），鱼鹰这样的实现是有两个问题的。
1、首次运行计算有误，因为静态变量应该在运行任务之前就初始化的（不应该初始化为 0），而钩子函数是在任务运行之后才调用的，所以从开机以来的时间被累加到第一个运行任务中了，这肯定是有问题的，不过后面随着系统的运行，静态变量被持续更新，就不会再出现这个问题了。
2、为了减少修改，鱼鹰把线程的use_data当成一个变量使用了，实际上这个变量的功能应该是存储线程私有变量地址的，但是因为鱼鹰懒得修改太多代码，所以直接拿来用了。正因为如此，所以鱼鹰添加线程CPU计算时，只要修改很少的代码就可以了。
线程CPU的计算
目前我们已经能够通过钩子函数获取各个线程的CPU执行时间，现在就看该如何计算了。
为了计算各个线程的CPU使用率，我们需要确定计算周期，这里我们可以设置1秒计算一次。
其次，我们需要确定在哪个任务执行计算。
原理上来说，可以是系统中的任何一个任务，但是为了减少对系统的干扰，可以将计算工作放到优先级比较低的任务中进行，比如空闲任务。
现在，看看函数是如何实现的：
注释已经很详尽了，所以不多做讨论。主要说以下几点：
1、为什么需要关闭调度器，可以使用关中断吗？
关调度器是为了防止在获取各个线程执行时间时，因为系统调度而导致执行时间被更新，从而导致计算有误，所以需要关闭调度器。
那么为什么不使用关中断的方式呢？没有必要。一旦关中断，那么中断就无法响应了，所以在可以关调度器的情况下满足要求，就不应该关中断。
2、为什么分两步计算，为什么不将最终的计算放在第一个循环中执行呢？
节省时间，为了尽量减少关调度器的时间，能省一点是一点。毕竟只要能获取到关键信息，啥时候计算都一样。
3、因为线程CPU计算周期是自动计算的，所以，计算周期其实就是该函数的调用周期，即2秒调用一次，那么线程CPU计算周期就是2秒，但是需要注意的是，调用周期必须小于定时器的溢出时间，即当你使用 DWT 时，调用周期应该在 60 秒以下（72 M 系统时钟），否则计算是有问题的。
现在我们已经算是完成了线程CPU计算问题，但为了使用方便，我们需要把它打印出来，或者把这些信息字符串化：
这里将线程名、线程执行时间、线程使用率都打印出来了，但是需要注意的是，这里的time 时间单位是定时器的单位，而不是微秒、毫秒，比如如果使用 DWT，那么单位就是 1/72 微秒，即如果 time 值为 1000，那么换算到微秒，应该是 1000/72 秒，当然了，你也可以在打印的同时就把时间换算一下，这个自由发挥就好。
最后，鱼鹰将代码提交到了 RT-Thread 官方工程里面，这是鱼鹰第一次使用Git 提交开源项目（操作不熟练，还是上网搜的教程），也不知道最后合并了没有。
如果对完整代码感兴趣的，也可以在后台回复关键字领取。
喜欢的话，记得关注鱼鹰哦！
