河南高端网站建设,广州市国外网站建设平台,摄影网站 源码,怎么制作一个游戏app2.2.2 调度的目标
当系统中“想运行”的实体多于 CPU 的数量时#xff0c;调度就不可避免地要在“效率”与“公平”之间做取舍。直观地说#xff0c;一类目标希望把硬件压榨到更高的利用率#xff0c;让单位时间内做更多的工作#xff1b;另一类目标则关心个体体验#x…2.2.2 调度的目标
当系统中“想运行”的实体多于 CPU 的数量时调度就不可避免地要在“效率”与“公平”之间做取舍。直观地说一类目标希望把硬件压榨到更高的利用率让单位时间内做更多的工作另一类目标则关心个体体验让单个作业或交互请求更早得到处理、等待更少、响应更稳。把这些目标与度量对应起来读者在分析不同算法时才知道“该看哪一项数据”。
2.2.2.1 通用度量与直观目标
衡量调度“好不好”通常不会只看单一指标而是几项度量的组合。为了建立直觉可以先把它们对齐到常见的体验或运营诉求上再进入正式术语。
1CPU 利用率期望处理机尽量“有活可干”空转比例越低越好。该指标体现硬件使用效率是长周期运营视角的核心目标之一。
2吞吐量单位时间内完成的作业数量越多越好。它对应“单位时间干了多少活”常与 CPU 利用率一起考量系统整体产出。
3周转时间平均周转时间从作业提交到作业完成所经历的总时间希望越短越好为了兼顾不同规模作业常配合带权周转时间讨论“公平的快慢”。
4等待时间作业在就绪队列中“干等 CPU”的累计时间希望越短越好它直接反映调度是否让作业长时间排队。
5响应时间交互或时间分片场景下从请求发出到系统首次给出可感知反馈的时间希望越短且越稳定。对终端用户而言响应时间往往比“最终完成得多快”更重要。
6可预测性抖动小相同类型任务的等待与响应不应忽快忽慢。对在线业务与实时场景稳定性与一致性本身就是目标。
这些度量彼此牵制例如追求极致吞吐量时个体响应可能变差强压响应时间时CPU 利用率与吞吐量可能下降。理解这种张力是做出“场景化选择”的前提。
2.2.2.2 不同系统类型的侧重
并非所有系统对目标的偏好都一样。把典型环境分开放可以更清晰地理解调度“在乎什么”。
1批处理系统更关注吞吐量与平均周转时间同时力求较高的CPU 利用率。批处理负载通常无人交互短作业不应长期被长作业压制因此在追求整体产出时也要兼顾等待时间与“对短作业的友好度”。
2交互式系统更看重响应时间与可预测性。用户希望“点一下就有反应”哪怕最终计算稍慢也能接受。因此调度应优先保证前台任务的及时切片与反馈同时避免某些低优先级任务饥饿。
3实时系统目标从“平均更好”转为“按时完成”。硬实时强调截止期满足率与时间行为的确定性软实时则在保证核心任务按时的前提下追求整体资源利用率。这里“可预测性”与“优先级约束”比平均指标更重要。
把系统类型与指标偏好对齐有助于在题目给出“工作负载背景”时迅速判断该优先哪一类目标。
2.2.2.3 公平与优先的平衡
仅有平均指标并不能说明一切。实践中还需要处理“谁更重要”与“是否被长期忽视”的问题。调度在这方面的目标主要体现在两点一是公平性即相近类别的作业应获得相近的处理机机会避免因偶然因素产生极端差异二是避免饥饿在长期运行中不让低优先级或长作业一直得不到服务。常见的做法是通过优先级表达相对重要性再以老化机制等手段在长期统计上恢复公平。对考研解题而言看到“长期无响应”“低优先级作业一直排队”等描述就要联想到“饥饿”“公平”“老化”这些目标词。
2.2.2.4 面向整体效率的协同取舍
除了单点指标调度还要实现不同资源之间的协同CPU、IO 设备与内存最好都“有活干”。因此目标上会鼓励IO 密集型与CPU 密集型任务的并行推进以提升系统整体吞吐量和设备利用率同时也希望上下文切换开销不过度膨胀避免因频繁切换而把时间花在“换人不干活”上。换言之调度既关注“选对人上场”也关注“别老换人”。这些都是目标层面的取舍具体如何达成留待后续实现与算法小节展开。
2.2.2.5 用目标指导算法选择的思路
面对具体场景读者可以按“负载特征—系统类型—关键目标”的顺序筛选算法侧重若题干强调“用户交互卡顿”优先关注响应时间可预测性若强调“批量作业堆积”优先关注吞吐量平均周转时间若出现“截止期”“定时任务”自然转向按时完成与确定性。在此基础上再考虑公平与避免饥饿的长期约束。记住调度算法的“好坏”不是抽象的而是相对于这一节明确的目标而言的。
