408/912-notes
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

modify some mistakes in chp15.md.

Browse Source
This commit is contained in:
Shine wOng
2019-09-16 19:16:44 +08:00
parent 259f9612b2
commit b78d975a9d
1 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
thu_os/chp15.md
View File

@@ -57,7 +57,7 @@
容易注意到，无论是SPN还是SRT算法，都具有一个问题：在短进程持续不断地到达的情况下，早已经进入就绪队列的长进程迟迟得不到执行，就会导致长进程的饥饿现象。
此外，两种算法都需要预先知道进程的执行时间，即需要预测未来，这是难以做到的，一种做法是向用户询问，但是用户也许为了更快得到执行而给出一个很短的执行时间来欺骗操作系统，在这种情况下可以无论用户进程是否执行完毕，时间到了总是进行调度。另一种做法和页面置换算法中的LRU算法类似，利用历史数据来估计未来，一种可行的时间方法是总是保存该进程历史执行时间，利用下面的公式来预估未来的执行时间：
此外，两种算法都需要预先知道进程的执行时间，即需要预测未来，这是难以做到的，一种做法是向用户询问，但是用户也许为了更快得到执行而给出一个很短的执行时间来欺骗操作系统，在这种情况下可以无论用户进程是否执行完毕，时间到了总是进行调度。另一种做法和页面置换算法中的LRU算法类似，利用历史数据来估计未来，一种可行的实现方法是总是保存该进程历史执行时间，利用下面的公式来预估未来的执行时间：
$$
\tau_{n+1} = \alpha t_n + (1 - \alpha)\tau_n
@@ -71,9 +71,9 @@ $$
利用该算法对进程执行时间的预估如下图所示：
![estimate_time](estimate_time.png)
![estimate_time](images/estimate_time.png)
### 最高响应比优先算法（HRRN, Highest Response Ration Next）
### 最高响应比优先算法（HRRN, Highest Response Ratio Next）
最高响应比优先算法是在SPN的基础上提出的。前面我们指出，SPN算法对于长进程有可能产生饥饿现象。HRRN算法就是为了解决这个问题，而在SPN的基础上改进提出的。
@@ -97,7 +97,7 @@ HRRN算法就是在每次调度时，总是选择响应比最高的进程，让
还有一个问题，RR算法中时间片长度的选择也需要重点考虑。如果时间片取得过大，比如任何进程都可以在一个时间片内完成执行，则RR算法就退化成了FCFS算法；而如果时间片取得过小，则会产生频繁的进程切换，这些额外的开销会影响到系统的吞吐量。前面提到过，进程的运行模式通常是CPU运算和I/O操作交替进行，如下图所示：
![process_running](images/proces_running.png)
![process_running](images/process_running.png)
可以看到，每次CPU运行时间几乎总是在8ms以内。如果时间片取得过短，则进程可能在本次的CPU运算完成之前就被迫放弃CPU的使用权，下次进入调度时，又只能运行很短的时间就会因为等待I/O资源而被阻塞。在这种情况下，进程执行效率很低，资源的利用率比较低下。因此，时间片的选择以应该恰好可以覆盖一次CPU的运行时间为宜，并且维持上下文切换具有较小的开销，比如在1%以内。