cha35.进程优先级和调度
读书笔记
nice
nice值形象的说是一个进程的友好(nice)程度,越nice(nice值数值越大的)的进程越礼让,多个任务争用cpu的时候越礼让。(本书中高nice值表示nice值数值更低,更不nice
- 取值范围为(-20(不友好,高优先级)-19(友好,低优先级))
- fork、exec时继承nice值
RLIMIT_NICE
资源限制,特权进程最高可以将nice值提升到20-RLIMIT_NICE
getpriority, setpriority
获取/设置nice值,getpriority可能返回负值,调用前将errno
置0,调用后结合errno
判断是否失败
实时调度
这里的实时调度和本科时的知识有些出入
- 为外部输入保证最大相应时间
- 高优先级进程互斥访问cpu
- 实时应用能精确控制其组件进程的调度顺序
linux内核2.617开始,支持的硬实时
几种调度策略
策略 | 特性 |
---|---|
SCHED_RR | 多级队列+时间片 |
SCHED_FIFO | 多级队列+先入先出+没有时间片 |
SCHED_OTHER | 非实时调度(默认) |
SCHED_BATCH | |
SCHED_IDLE | |
感觉这本书有点老了,这篇文章看起来和本科的很接近 |
实时api
API | 作用 |
---|---|
sched_setscheduler | 设置pid的调度策略,见上一节 |
sched_setparam | 将pid移动到指定优先级队列的队尾 |
sched_getscheduler | 获取pid的调度策略 |
sched_getparam | 获取pid的优先级 |
sched_yield | 释放CPU |
sched_rr_get_interval | 获取rr时间片 |
cpu亲和力
多cpu系统中,为了减少因进程切换cpu导致的高速缓冲失效的情况,将进程绑定到一个/一组CPU中
- API
sched_getaffinity
sched_setaffinity
35.1
实现nice命令
1 | // |
35.2
编写一个与nice(1)命令类似的实时调度程序set-user-ID-root程序。这个程序的命令
行界面如下所示:
1 | # ./rtsched policy priority command arg.. |
在上面的命令中,policy 中r表示SCHED RR,f表示SCHED FIFO。基于在9.7.1
节和38.3 节中描述的原因,这个程序在执行命令前应该丢弃自己的特权ID。
1 | // |
35.3
编写一个运行于SCHED FIFO调度策略下的程序,然后创建一个子进程。在两个
进程中都执行一个能导致进程最多消耗3秒CPU时间的函数。(这可以通过使用
一个循环并在循环中不断使用 times()系统调用来确定累积消耗的CPU时间来完
成。每当消耗了 1/4秒的CPU时间之后,函数应该打印出一条显示进程ID和迄
今消耗的CPU时间的消息。每当消耗了1秒的CPU 时间之后,函数应该调用
sched yield0来将CPU释放给其他进程另一种方法是进程使用sched setparam(
提升对方的调度策略。)从程序的输出中应该能够看出两个进程交替消耗了1秒
的CPU时间。(注意在35.3.2节中给出的有关防止失控实时进程占住CPU的建
议。)
1 |
|
35.4
如果两个进程在一个多处理器系统上使用管道来交换大量数据,那么两个进程
运行在同一个CPU上的通信速度应该要快于两个进程运行在不同的CPU上
其原因是当两个进程运行在同一个 CPU 上时能够快速地访问管道数据,因为
管道数据可以保留在 CPU的高速缓冲器中。相反,当两个进程运行在不同的
CPU上时将无法享受CPU高速缓冲器带来的优势。读者如果拥有多处理器系
统可以编写一个使用sched setaffinity0强制将两个进程运行在同一个CPU上
或运行在两个不同的CPU上的程序来演示这种效果。(第44 章描述了管道的
使用。)
1 | // |
测试
1 | time `find / | ./practice35.4 1 | ./practice35.4 1` |
经过几次测试,确实同一个cpu会快一点