|
|
|
Modern Operating Systems by Herbert Bos and Andrew S. Tanenb...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf
Showing 185-186 out of 1137
Modern Operating Systems by Herbert Bos and Andrew...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Modern Operating Systems by Herbert...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Page 185
154
PROCESSES AND THREADS
CHAP. 2
In systems with real-time constraints, preemption is, oddly enough, sometimes
not needed because the processes know that they may not run for long periods of
time and usually do their work and block quickly. The difference with interactive
systems is that real-time systems run only programs that are intended to further the
application at hand. Interactive systems are general purpose and may run arbitrary
programs that are not cooperative and even possibly malicious.
Scheduling Algorithm Goals
In order to design a scheduling algorithm, it is necessary to have some idea of
what a good algorithm should do. Some goals depend on the environment (batch,
interactive, or real time), but some are desirable in all cases. Some goals are listed
in Fig. 2-40.
We will discuss these in turn below.
All systems
Fairness - giving each process a fair share of the CPU
Policy enforcement - seeing that stated policy is carried out
Balance - keeping all parts of the system busy
Batch systems
Throughput - maximize jobs per hour
Turnaround time - minimize time between submission and termination
CPU utilization - keep the CPU busy all the time
Interactive systems
Response time - respond to requests quickly
Proportionality - meet users’ expectations
Real-time systems
Meeting deadlines - avoid losing data
Predictability - avoid quality degradation in multimedia systems
Figure 2-40.
Some goals of the scheduling algorithm under different circumstances.
Under all circumstances, fairness is important. Comparable processes should
get comparable service.
Giving one process much more CPU time than an equiv-
alent one is not fair.
Of course, different categories of processes may be treated
differently.
Think of safety control and doing the payroll at a nuclear reactor’s
computer center.
Somewhat related to fairness is enforcing the system’s policies. If the local
policy is that safety control processes get to run whenever they want to, even if it
means the payroll is 30 sec late, the scheduler has to make sure this policy is
enforced.
Another general goal is keeping all parts of the system busy when possible.
If
the CPU and all the I/O devices can be kept running all the time, more work gets
Page 186
SEC. 2.4
SCHEDULING
155
done per second than if some of the components are idle.
In a batch system, for
example, the scheduler has control of which jobs are brought into memory to run.
Having some CPU-bound processes and some I/O-bound processes in memory to-
gether is a better idea than first loading and running all the CPU-bound jobs and
then, when they are finished, loading and running all the I/O-bound jobs.
If the lat-
ter strategy is used, when the CPU-bound processes are running, they will fight for
the CPU and the disk will be idle. Later, when the I/O-bound jobs come in, they
will fight for the disk and the CPU will be idle. Better to keep the whole system
running at once by a careful mix of processes.
The managers of large computer centers that run many batch jobs typically
look at three metrics to see how well their systems are performing: throughput,
turnaround time, and CPU utilization.
Throughput
is the number of jobs per hour
that the system completes. All things considered, finishing 50 jobs per hour is bet-
ter than finishing 40 jobs per hour.
Turnaround time
is the statistically average
time from the moment that a batch job is submitted until the moment it is com-
pleted. It measures how long the average user has to wait for the output.
Here the
rule is: Small is Beautiful.
A scheduling algorithm that tries to maximize throughput may not necessarily
minimize turnaround time. For example, given a mix of short jobs and long jobs, a
scheduler that always ran short jobs and never ran long jobs might achieve an ex-
cellent throughput (many short jobs per hour) but at the expense of a terrible
turnaround time for the long jobs.
If short jobs kept arriving at a fairly steady rate,
the long jobs might never run, making the mean turnaround time infinite while
achieving a high throughput.
CPU utilization is often used as a metric on batch systems. Actually though, it
is not a good metric.
What really matters is how many jobs per hour come out of
the system (throughput) and how long it takes to get a job back (turnaround time).
Using CPU utilization as a metric is like rating cars based on how many times per
hour the engine turns over. However, knowing when the CPU utilization is almost
100% is useful for knowing when it is time to get more computing power.
For interactive systems, different goals apply. The most important one is to
minimize
response time
, that is, the time between issuing a command and getting
the result.
On a personal computer where a background process is running (for ex-
ample, reading and storing email from the network), a user request to start a pro-
gram or open a file should take precedence over the background work. Having all
interactive requests go first will be perceived as good service.
A somewhat related issue is what might be called
proportionality
.
Users have
an inherent (but often incorrect) idea of how long things should take. When a re-
quest that the user perceives as complex takes a long time, users accept that, but
when a request that is perceived as simple takes a long time, users get irritated. For
example, if clicking on an icon that starts uploading a 500-MB video to a cloud
server takes 60 sec, the user will probably accept that as a fact of life because he
does not expect the upload to take 5 sec. He knows it will take time.
Ace your assessments! Get Better Grades
Browse thousands of Study Materials & Solutions from your Favorite Schools
Concordia University
Concordia_University
School:
Operating_Systems
Course:
Great resource for chem class. Had all the past labs and assignments
Leland P.
Santa Clara University
Introducing Study Plan
Using AI Tools to Help you understand and remember your course concepts better and faster than any other resource.
Find the best videos to learn every concept in that course from Youtube and Tiktok without searching.
Save All Relavent Videos & Materials and access anytime and anywhere
Prepare Smart and Guarantee better grades
Know more
Students also viewed documents
lab 18.docx
lab_18.docx
Course
Course
3
Module5QuizSTA2023.d...
Module5QuizSTA2023.docx.docx
Course
Course
10
Week 7 Test Math302....
Week_7_Test_Math302.docx.docx
Course
Course
30
Chapter 1 Assigment ...
Chapter_1_Assigment_Questions.docx.docx
Course
Course
5
Week 4 tests.docx.do...
Week_4_tests.docx.docx
Course
Course
23
Week 6 tests.docx.do...
Week_6_tests.docx.docx
Course
Course
106
