内核资料收集
1. 传统unix系统的调度算法要实现几个互相冲突的目标:
a. 进程响应时间尽可能的快
b. 后台作业的吞量尽可以的高
c. 尽可能避免进程的饥饿现象
d. 低优先级和高优先级进程需要尽可能调和
决定什么时候以怎样的方式选择一个新的进程运行的这组规则就是所谓调度策略(scheduling policy)
2. linux调度基于分时(time sharing)技术:
a. 多个进程以"时间多路利用"的方式运行, CPU时间被分成"片(slice)", 给每个可运行进程分配一片.
b. 单处理器在任何给定的时刻只能运行一个进程.
c. 当前运行进程的时间片或时限(quantum)到期, 该进程还没运行完毕, 进程切换就可以发生.
d. 分时依赖于定时中断, 因此对进程是透明的. 无需在程序中插入额外的代码保证CPU分时.
3. 调度策略是根据进程的优先级对它们进行分类. 每个进程都与一个值相关联, 这个值表示把进程如何适当地分配给CPU.
linux中, 进程的优先级是动态的. 调度程序跟踪进程正在做什么, 并周期性的调整它们的优先级. 在此种方式下, 较长时间间隔
内没有使用CPU的进程, 通过动态增加优先级来提升它们. 相应地, 对于已经在CPU上运行了较长时间的进程, 通过减少它们的优
先级来"处罚"它们.
4. 进程分类
传统上把进程分类为:
a. "I/O受限(I/O-bound)", 频繁使用I/O设备, 并花费大量时间等待I/O操作完成.
b. "CPU受限(CPU-bound)", 需要大量CPU时间的数值计算.
另一种分类:
a. 交互式进程
经常与用户进行交互,因此要花费很多时间等待键盘, 鼠标操作. 当接受输入后,进程必须被很快唤醒, 否则用户将发现系统
反应迟钝. 典型的交互式程序是命令shell, 文本编辑及图形应用程序
b. 批处理进程
不必与用户交互, 经常在后台运行. 因此不必很快响应, 因此受到调度程序慢待. 典型批处理程序是程序设计语言的编译程序,
数据库搜索引擎及科学计算.
c. 实时进程
此种程序有很强的调度需要. 这样的进程决不会被低优先级的进程阻塞, 它们应该有一个很短的响应时间, 响应时间的变化
应该很小. 典型应用是视频, 音频应用, 机器人控制, 从物理传感器上收集数据等.
以上两种分类方法互相独立. 如一个批处理进程可能是I/O受限型的(如数据库服务器), 也可能是CPU受限型的(如绘图程序).
linux中,调度算法可以明确地确认所有实时程序的身份, 但没有办法区分交互式程序和批处理程序. linux2.6调度程序实现了基
于进程过去行为的启发式算法, 以确定进程应该被当作交互式进程还是批处理进程. 与批处理进程相比, 调度程序有偏爱交互式
进程的倾向.
5. 调度相关的系统调用
nice() 改变普通进程的静态优先级
getpriority() 获得一组普通进程的最大静态优先级
setpriority() 设置一组普通进程的静态优先级
sched_getscheduler() 获取一个进程的调度策略
sched_setscheduler() 设置一个进程的调度策略和实时优先级
sched_getparam() 获取一个进程的实时优先级
sched_setparam() 设置一个进程的实时优先级
sched_yield() 自愿放弃处理器而不阻塞
sched_get_priority_min() 获得一种策略的最小实时优先级
sched_get_priority_max() 获得一种策略的最大实时优先级
sched_rr_get_interal() 获得时间片轮转策略的时间片值
sched_setaffinity() 设置进程的CPU亲和力掩码
sched_getaffinity() 获得进程的CPU亲和力掩码
6. 进程抢占
linux进程是抢占式的. 如果进程进入TASK_RUNNING状态, 内核检查它的动态优先级是否大于当前进程的优先级. 如果是,
current的执行被中断, 并调用调度程序选择另一个进程运行(通常是刚刚变为可运行的进程) . 当然, 进程在它的时间片到期时也
可以被抢占. 此时, 当前进程的thread_info结构中的TIF_NEED_RESCHED标志被设置, 以便时钟处理程序终止时调度程序被调用.
例如: 考虑一个文本编辑程序和一个编译程序正在执行......
7. 一个时间片必须多长?
时间片的长短对系统性能很关键: 不能太长也不能太短
如果时间片太短: 进程切换引起的系统额外开销就变得非常高.
例如, 假定时间片设置为5ms, 进程切换时间也要5ms, 那么CPU至少把50%时间花费在进程切换上.
如果平均时间太长: 进程看起来不再是并发执行.
例如, 假定时间片设置为5s, 每个进程运行大约5s, 但暂停时间更长(一般是5s乘以可运行进程的个数)
交互式进程相对有较高的优先级, 因此, 不管时间片多长, 它们都会很快抢占批处理进程
在一些情况下, 一个太长的时间片会降低系统的响应能力. 例如, 假定两个用户在各自的shell提示符下并发输入两条命令,
其中一条启动一个CPU受限进程, 而另一条启动一个交互应用. 两个shell都创建一个新的进程, 并把用户的执行委托给新进程.
此外, 又假定这样的新进程最初有相同的优先级. 现在, 如果调度程序选择CPU受限型进程执行, 则另一个进程开始执行前就
可能要等待一个时间片. 因此, 如果这样的时间片较长, 那么看起来系统就可能对用户的请求反应迟钝.
对时间片大小的选择始终是一种折衷. linux采取单凭经验的方法, 即选择尽可能长, 同时能保待良好响应时间的时间片.
阅读(748) | 评论(0) | 转发(0) |
