Process Scheduling in Operating Systems: Policies, Priorities, and Algorithms, Study notes of Operating Systems

Download Process Scheduling in Operating Systems: Policies, Priorities, and Algorithms and more Study notes Operating Systems in PDF only on Docsity!

CS 3210

Spring 2005

Process

Scheduling

CS 3210 Operating System Design Hutto, College of Computing, Georgia Tech

Process Scheduling z

scheduler: who gets to run next z

scheduler (policy) vs. dispatcher (mechanism) z

process abstraction + scheduler

virtualizes

CPU

z

other "schedulers" also exist in kernel z

io schedulers: packet scheduler, disk scheduler z

"proto-OS" switched between apps while waiting for i/o z

goal: maximize CPU utilization z

lots of theory but … z

real-world schedulers need to be general purpose z must meet many competing demands, job mixes z throughput, responsiveness, priorities, no starvation, …

CS 3210 Operating System Design Hutto, College of Computing, Georgia Tech

Process Scheduling z

preemption z

higher priority process takes CPU from lower priority

z

…even if time slice has not yet expired

z time-sharing z

each process given a time slice or quantum

z

once scheduled, run until… z

blocking z termination z slice expires (check at timer interrupt) z higher priority process becomes runnable (preemption) z

select another task to run, context switch

CS 3210 Operating System Design Hutto, College of Computing, Georgia Tech

Process Priorities andFairness z

priority and fairness are antagonistic z Linux provides priorities but still tries to be fair z general rules: z decrease priority of processes that run a lot z increase priority of processes that sleep a lot z avoid starvation (aging) z boost "interactive" processes

CS 3210 Operating System Design Hutto, College of Computing, Georgia Tech

Scheduling System Calls z

nice() z

lower priority (be nice to other people)

z

root can increase

z

niceness is opposite of priority z

increasing (+) nice decrease priority z decreasing (-) nice increases priority z get/setpriority() z sched_get/setscheduler() z sched_get/setparam() z sched_yield()

CS 3210 Operating System Design Hutto, College of Computing, Georgia Tech

Quantum Length z

how long? similar to timer interrupt frequency z too short – too much time spent switching z like "thrashing", spending too much time swapping z too long – processes feel unresponsive z you run longer but you also wait longer z priority, interrupts also increase response z 2.4 uses about 10 ticks (105 ms)

CS 3210 Operating System Design Hutto, College of Computing, Georgia Tech

Realtime Processes z

higher priority than "regular" processes z can be created only by root z can disrupt system if poorly programmed z Windows has three levels: z regular, system, realtime z realtime processes have priority too (1-99) z so called "static priority" (though can be changed) z used to differentiate rt processes z always higher than regular process priorities

CS 3210 Operating System Design Hutto, College of Computing, Georgia Tech

Scheduling Relatedtask_struct Fields z

nice – base quantum (-20 to +19) z counter – ticks remaining in quantum z rt_priority – 0 (regular) to 99 z policy - regular or realtime z SCHED_OTHER – regular z SCHED_FIFO – realtime, "run to completion" z SCHED_RR – realtime, quantum but no epoch z need_resched z processor, cpus_allowed, cpus_runnable z aligned_data – per-processor struct z curr – task_struct of current z last_schedule – TSC value of last process switch

CS 3210 Operating System Design Hutto, College of Computing, Georgia Tech

Invoking schedule() z

Direct invocation z when a process blocks in the kernel z sometime by device drivers to yield CPU z Lazy invocation z need_resched bit z checked on transition from kernel to user z on quantum expiration z for preemption (wakeup/creation of higher priority) z on sched_setscheduler() or sched_yield()

CS 3210 Operating System Design Hutto, College of Computing, Georgia Tech

schedule(): preliminaries z

goal: z set next to task_struct of next process z call switch_to(prev, next, prev) z acquire spinlock, disable interrupts toexamine runqueue z special case for exhausted SCHED_RRprocess z update state and need_resched

CS 3210 Operating System Design Hutto, College of Computing, Georgia Tech

schedule(): epoch z

iterate through tasklist (not runqueue!) z replenish quantum if expired z add to non-zero quanta of blocked processes z i/o boost (bounded)

CS 3210 Operating System Design Hutto, College of Computing, Georgia Tech

schedule(): after epoch z

prev == next special case z update some kernel statistics z address space switch for kernel threads z invoke switch_to() z code after switch_to() executed when prev isrescheduled again in the future z uniprocessor – not much z multiprocessor – try to reschedule prev

CS 3210 Operating System Design Hutto, College of Computing, Georgia Tech

reschedule_idle() z

called in "tail" of schedule() on MP z tries to reschedule prev on another CPU z is last processor prev ran on idle? z what's the "oldest idle" processor? z is there a process with lower priority running? z uses IPI to initiate reschedule

CS 3210 Operating System Design Hutto, College of Computing, Georgia Tech

Hyper-threading z

Looks like two processors z No special enhancements in 2. z Except when ht processor runs 2 idles z breaks the "oldest idle" rule in reschedule_idle() z 2.6 has more enhancements z hyper-threads not the same as real CPUs z probably dual-core enhancements coming