cpu时间片原理说明

随心所欲的小强

已于 2023-10-11 14:12:56 修改

阅读量3.3k

点赞数 6

分类专栏： linux内核文章标签：嵌入式硬件 linux 运维 c语言服务器

于 2023-09-28 17:52:43 首次发布

本文链接：https://blog.csdn.net/tombaby_come/article/details/133387066

版权

linux内核专栏收录该内容

12 篇文章

订阅专栏

一、简介

1、cpu时间片的概念

时间片即CPU分配给各个程序的时间，每个线程被分配一个时间段，称作它的时间片，即该进程允许运行的时间，使各个程序从表面上看是同时进行的。如果在时间片结束时进程还在运行，则CPU将被剥夺并分配给另一个进程。如果进程在时间片结束前阻塞或结束，则CPU当即进行切换。而不会造成CPU资源浪费。在宏观上：我们可以同时打开多个应用程序，每个程序并行不悖，同时运行。但在微观上：由于只有一个CPU，一次只能处理程序要求的一部分，如何处理公平，一种方法就是引入时间片，每个程序轮流执行。

2、cpu时间片基本原理

在早期的时间片轮转法中,系统将所有的就绪进程按先来先服务的原则,排成一个队列,每次调度时,把CPU分配给队首进程,并令其执行一个时间片.时间片的大小从几ms到几百ms.当执行的时间片用完时,由一个计时器发出时钟中断请求,调度程序便据此信号来停止该进程的执行,并将它送往就绪队列的末尾;然后,再把处理机分配给就绪队列中新的队首进程,同时也让它执行一个时间片.这样就可以保证就绪队列中的所有进程,在一给定的时间内,均能获得一时间片的处理机执行时间.

3、系统中cpu时间片是多久

Windows 系统中线程轮转时间也就是时间片大约是20ms，如果某个线程所需要的时间小于20ms，那么不到20ms就会切换到其他线程;如果一个线程所需的时间超过20ms，系统也最多只给20ms，除非意外发生(那可能导致整个系统无响应)，而Linux/unix中则是5~800ms。

4、cpu时间片轮转机制(RR 调度)

时间片轮转法(Round-Robin，RR)主要用于分时系统中的进程调度。为了实现轮转调度，系统把所有就绪进程按先入先出的原则排成一个队列。新来的进程加到就绪队列末尾。每当执行进程调度时，进程调度程序总是选出就绪队列的队首进程，让它在 CPU 上运行一个时间片的时间。时间片是一个小的时间单位，通常为 10~100ms 数量级。当进程用完分给它的时间片后，系统的计时器发出时钟中断，调度程序便停止该进程的运行，把它放入就绪队列的末尾;然后，把 CPU 分给就绪队列的队首进程，同样也让它运行一个时间片，如此往复。

进程调度

采用此算法的系统，其程序就绪队列往往按进程到达的时间来排序。进程调度程序总是选择就绪队列中的第一个进程，也就是说按照先来先服务原则调度，但一旦进程占用处理机则仅使用一个时间片。在使用先一个时间片后，进程还没有完成其运行，它必须释放出处理机给下一个就绪的进程，而被抢占的进程返回到就绪队列的末尾重新排队等待再次运行。

处理器同一个时间只能处理一个任务。处理器在处理多任务的时候，就要看请求的时间顺序，如果时间一致，就要进行预测。挑到一个任务后，需要若干步骤才能做完，这些步骤中有些需要处理器参与，有些不需要(如磁盘控制器的存储过程)。不需要处理器处理的时候，这部分时间就要分配给其他的进程。原来的进程就要处于等待的时间段上。经过周密分配时间，宏观上就象是多个任务一起运行一样，但微观上是有先后的，就是时间片轮换。

实现思想

时间片轮转算法的基本思想是，系统将所有的就绪进程按先来先服务算法的原则，排成一个队列，每次调度时，系统把处理机分配给队列首进程，并让其执行一个时间片。当执行的时间片用完时，由一个计时器发出时钟中断请求，调度程序根据这个请求停止该进程的运行，将它送到就绪队列的末尾，再把处理机分给就绪队列中新的队列首进程，同时让它也执行一个时间片。

5、cpu时间片轮转调度算法

时间片轮转调度是一种最古老，最简单，最公平且使用最广的算法。每个进程被分配一时间段，称作它的时间片，即该进程允许运行的时间。

如果在时间片结束时进程还在运行，则CPU将被剥夺并分配给另一个进程。如果进程在时间片结束前阻塞或结束，则CPU当即进行切换。调度程序所要做的就是维护一张就绪进程列表，当进程用完它的时间片后，它被移到队列的末尾。

时间片轮转调度中唯一有趣的一点是时间片的长度。从一个进程切换到另一个进程是需要一定时间的--保存和装入寄存器值及内存映像，更新各种表格和队列等。假如进程切换(process switch) - 有时称为上下文切换(context switch)，需要5毫秒，再假设时间片设为20毫秒，则在做完20毫秒有用的工作之后，CPU将花费5毫秒来进行进程切换。CPU时间的20%被浪费在了管理开销上。

为了提高CPU效率，我们可以将时间片设为500毫秒。这时浪费的时间只有1%。但考虑在一个分时系统中，如果有十个交互用户几乎同时按下回车键，将发生什么情况?假设所有其他进程都用足它们的时间片的话，最后一个不幸的进程不得不等待5秒钟才获得运行机会。多数用户无法忍受一条简短命令要5秒钟才能做出响应。同样的问题在一台支持多道程序的个人计算机上也会发生。

结论可以归结如下：时间片设得太短会导致过多的进程切换，降低了CPU效率;而设得太长又可能引起对短的交互请求的响应变差。将时间片设为100毫秒通常是一个比较合理的折中。

通过以上的内容，我们已经了解了cpu时间片方面的相关知识了，对于时间片的基本原理以及轮转机制方面的内容，也可以多多的了解下。

二、原理

了解了上面的概念后，你可能对cpu的时间片认知还是懵懵懂懂的，它到底是怎么个原理？为什么要这么做？这么做有什么好处？与它相关的专业术语和理论又有什么关联性？我怎么能深刻的理解它的原理？接下来就是本文的重点内容，让我们来一起探索下。

1、类比生活场景解释cpu时间片的发展和理论原理

先来设定下生活中的场景和角色：

场景：餐馆

角色：

（1）厨师（专心炒菜）

（2）后厨帮手（负责给厨师打下手的学徒之类，负责备菜递盘等等相较为低级一些的事情）

（3）服务员（负责响应顾客，并且通知后厨顾客的需求）

（4）顾客（专心消费）

场景设定：店里依次排队进来了5个顾客，每个人都点了一个菜

核心问题：上菜速度怎么样？怎么最快的把菜炒完。

厨师怎么怎么处理顾客的点单，才能让顾客在最短的时间吃到菜

店里来了5个客人，每个人都点了一个菜，如下：

顾客1第一个下单：菜1——青椒炒肉——大约需要5分钟

顾客2第二个下单：菜2——土豆牛腩——大约需要25分钟

顾客3第三个下单：菜3——红烧鸡块——大约需要15分钟

顾客4第四个下单：菜4——青椒炒鸡蛋——大约需要3分钟

顾客5第五个下单：菜5——宫保鸡丁——大约需要4分钟

方案一：先到先得方法

按照先到先得方法最终到厨师手里的炒菜单顺序是：

1.菜1——青椒炒肉（5分钟）

2.菜2——土豆牛腩（25分钟）

3.菜3——红烧鸡块（15分钟）

4.菜4——青椒炒鸡蛋（3分钟）

5.菜5——宫保鸡丁（4分钟）

总耗时：5min+25min+15min+3min+4min=52min

各个顾客等待时间：

1.顾客1：菜1——青椒炒肉（5分钟）——等待5分钟

2.顾客2：菜2——土豆牛腩（25分钟）——等待30分钟

3.顾客3：菜3——红烧鸡块（15分钟）——等待45分钟

4.顾客4：菜4——青椒炒鸡蛋（3分钟）——等待48分钟

5.顾客5：菜5——宫保鸡丁（4分钟）——等待52分钟

平均等待时间：（5+30+45+48+52）/5=36分钟。

最长平均等待时间（最差情况）：

1.顾客2：菜2——土豆牛腩（25分钟）——等待25分钟

2.顾客3：菜3——红烧鸡块（15分钟）——等待40分钟

3.顾客1：菜1——青椒炒肉（5分钟）——等待45分钟

4.顾客5：菜5——宫保鸡丁（4分钟）——等待49分钟

5.顾客4：菜4——青椒炒鸡蛋（3分钟）——等待52分钟

平均等待时间：（25+40+45+49+52）/5=42.2分钟。

这明显的处理效率不够，顾客很可能不愿意等待，从而使得顾客流失，那我们可以进一步优化，采用优先级方法处理（优先处理时间短的事情）。

方案二：优先级方法

1.菜4——青椒炒鸡蛋（3分钟）

2.菜5——宫保鸡丁（4分钟）

3.菜1——青椒炒肉（5分钟）

4.菜3——红烧鸡块（15分钟）

5.菜2——土豆牛腩（25分钟）

总耗时：3min+4min+5min+15min+25min=52min

各个顾客等待时间：

1.菜4——青椒炒鸡蛋（3分钟）——顾客4——等待3分钟

2.菜5——宫保鸡丁（4分钟）——顾客5——等待7分钟

3.菜1——青椒炒肉（5分钟）——顾客1——等待12分钟

4.菜3——红烧鸡块（15分钟）——顾客3——等待27分钟

5.菜2——土豆牛腩（25分钟）——顾客2——等待52分钟

平均等待时间：（3+7+12+27+52）/5=18.2min

但是这种情况是最理想的状态，有时候顾客到来和下单的时间不能确定，如果顾客2先到达并且下单，那么平均等待时间将变为（引入下单时间，以第一个顾客下单时间为基准）：

1.菜2——土豆牛腩（25分钟）——顾客2下单——第一个优先级——等待25分钟

2.菜5——宫保鸡丁（4分钟）——顾客5在顾客2下单后1分钟后下单——第三个优先级——等待32分钟

3.菜1——青椒炒肉（5分钟）——顾客1在顾客2下单后2分钟下单——第四个优先级——等待37分钟

4.菜3——红烧鸡块（15分钟）——顾客3在顾客2下单后3分钟后下单——第五个优先级——等待52分钟

5.菜4——青椒炒鸡蛋（3分钟）——顾客4在顾客2下单后4分钟后下单——第二个优先级——等待28分钟

平均等待时间：（25+32+37+52+28）/5=34.8min。

虽然优先级算法可以节省一些场景的时间，但是受到实际下单时间的影响，可能性能还是不能够达到最优，那接着就引入了时间轮询方法。

方案三：时间轮询方法（就是我们本文的重点cpu时间片轮询）

首先，厨师手里的菜单如下，以5分钟为一个单位做为单个时间片处理结果将是：

1.菜2——土豆牛腩（25分钟）——顾客2下单——第一个优先级——制作5分钟后，暂停当前任务处理其他时间短的任务，第24分钟到28分钟第二次处理，第34分钟到38分钟第三次处理，第44分钟到48分钟第四次处理，第49分钟到53分钟第五次处理，共处理5次，总花费25分钟处理时间——等待25分钟

2.菜5——宫保鸡丁（4分钟）——顾客5在顾客2下单后1分钟后下单——第三个优先级——等待12分钟

3.菜1——青椒炒肉（5分钟）——顾客1在顾客2下单后2分钟下单——第四个优先级——等待17分钟

4.菜3——红烧鸡块（15分钟）——顾客3在顾客2下单后3分钟后下单——第五个优先级——第18分钟到23分钟处理一次，第29分钟到33分钟第二次处理，第39分钟到43分钟第三次处理，共处理3次，总花费15分钟处理时间——等待43分钟

5.菜4——青椒炒鸡蛋（3分钟）——顾客4在顾客2下单后4分钟后下单——第二个优先级——等待8分钟

平均等待时间：（53+12+17+43+8）/5=26.6min。

这时候无论顾客下单情况如何，都可以尽可能的让用户等待最少的时间。这就是时间片策略。

各个方案比较

维度	先到先得	优先级	时间轮询
最差平均等待时间	42.2min	34.8min	26.6min

这里可以看出，最差平均等待时间上，时间轮询策略是最优解。这也是当前cpu的时间片轮询策略的发展由来过程。

这时候，聪明的你会好奇，一个厨师只能在一个时间炒一个菜么？不能多几个锅灶，多几个厨师么？是的，可以，但是多请师傅，多增加锅灶就涉及到成本问题了。

在计算机领域，多请师傅意味着要增加cpu核，多给师傅配置锅灶要看师傅的能力（cpu是否支持处理多线程，如果师傅一个时间只能炒一个菜，那配置多余的锅灶也没有用，当师傅可以同时兼顾2个菜时，就是对应的cpu开启多线程，比如最常见的cpu双线程，一个cpu有两个线程）。因此，无论是增加cpu核，还是开启cpu多线程，都是需要硬件扩展和支持，而也对应着硬件成本的增加。而现在的芯片技术以及成本问题。也导致硬件不可能无限的扩增下去，我们仍然需要在调度策略上尽可能的利用硬件性能，争取最高的性价比。