为什么响应时间在CPU调度中很重要?

时间:2016-12-20 15:58:35

标签: operating-system scheduling

我正在寻找一个响应时间很重要的工作示例。

One definition of response time is

  

交互式程序从发出命令到开始对该命令的响应所花费的时间。

我已经知道响应时间对于交互性很重要,但我不明白为什么。如果作业没有完全完成,那么可以产生哪些用户感兴趣的输出?

用户不关心作业完成的时间,因为这是第一次产生任何输出吗?

例如,考虑这两个工作的两个可能的调度:

Case 1: |---B---|---A---|
Case 2: |-A-|---B---|-A-|

假设作业A和B同时发出,A是用户输入的命令,B是后台进程。

作业A的响应时间,据我所知,在案例2中会更短。由于作业A在两种情况下同时完成(并产生输出),我不明白用户如何受益(甚至通知)案例2中的响应时间更长。

2 个答案:

答案 0 :(得分:0)

在编写操作系统时,必须考虑目标读者的内容。在某些情况下,尽可能快地完成工作(超级计算机系统)是最重要的,在某些情况下,最重要的是尽可能地响应(常规桌面系统),并且在某些情况下最重要的是尽可能地预测(实时系统)。

对于尽快完成作业,任务应尽可能中断(任务切换之间的大间隔是最佳选择)。响应时间并不重要。应该注意的是,任务切换通常需要一些时间(通常是数千个CPU周期),因为必须将旧任务的状态(包括寄存器和分页结构)保存到存储器并恢复状态(包括寄存器和分页结构)。记忆中的新任务。这也会导致缓存和TLB未命中,因为缓存的信息通常不属于当前进程。

对于是最具响应性的,任务应尽可能经常中断,以免用户遇到所谓的滞后。这是响应时间很重要的地方。但请注意,在中断驱动的体系结构(如x86)上,来自键盘或鼠标的中断会自动暂停当前任务的执行并调用中断处理程序,中断处理程序处理输入并将其发送到相应的程序。

对于是最可预测的,输入既不应该太快,也不要太慢。这意味着响应时间受到两种方式的限制,因此比“响应性最强”的设计要重要得多。在任务关键型系统中,错误预测甚至可能是致命的失败。

简而言之,响应时间的重要性因设计而异,可能从几乎不重要到关键。

答案 1 :(得分:0)

我想我对自己的问题有了答案。问题是,我只是考虑像ls之类的简单流程,这些流程曾经发布了一段时间的运行,然后然后,当它们完成时,提供他们的第一个也是唯一的输出

但是,假设问题示例中的作业A是具有多个打印语句的程序。在这种情况下,输出将在过程完成之前生成 (并且在第一次调度的突发期间可能会出现一些打印输出)。因此,想要尽快开始运行这样的过程对于交互是有意义的。