Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
An in-depth exploration of Linux process scheduling, focusing on the concepts of run queues, priority arrays, and swapping arrays. It covers topics such as processor affinity, basic scheduling algorithm, calculating timeslices, dynamic priority, and interactive processes. The document also discusses the importance of two arrays and the role of Linux in real-time scheduling.
Typology: Lecture notes
1 / 40
This page cannot be seen from the preview
Don't miss anything!
The Linux scheduler tries to be very efficient
To do that, it uses some complex datastructures
Some of what it does actually contradicts theschemes we’ve been discussing...
Have a separate run queue for each processor
Each processor only selects processes from itsown queue to run
Yes, it’s possible for one processor to be idlewhile others have jobs waiting in their runqueues
Periodically, the queues are rebalanced: if oneprocessor’s run queue is too long, someprocesses are moved from it to anotherprocessor’s queue
Each process has a bitmask saying what CPUsit can run on
Normally, of course, all CPUs are listed
Processes can change the mask
The mask is inherited by child processes (andthreads), thus tending to keep them on thesame CPU
Rebalancing does not override affinity
140 separate queues, one for each priority level
Actually, that number can be changed at agiven site
Actually, two sets, active and expired
Priorities 0-99 for real-time processes
Priorities 100-139 for normal processes; valueset via nice() system call
There is a bit map indicating which queueshave processes that are ready to run
Find the first bit that’s set: u 140 queues ⇒ 5 integers u Only a few compares to find the first thatis non-zero u Hardware instruction to find the first 1-bit u Time depends on the number of prioritylevels, not the number of processes
Static Pri Niceness Quantum Highest Static Pri 100 20 800 ms High Static Pri 110
600 ms Normal 120 0 100 ms Low Static Pri 130 + 50 ms Lowest Static Pri 139 + 5 ms
Dynamic priority is calculated from staticpriority and average sleep time
When process wakes up, record how long itwas sleeping, up to some maximum value
When the process is running, decrease thatvalue each timer tick
Roughly speaking, the bonus is a number in [ , 10] that measures what percentage of the time the process was sleeping recently; 5 isneutral, 10 helps priority by 5, 0 hurts priorityby 5 DP = max ( , min ( SP − bonus
At every time tick, decrease the quantum ofthe current running process
If the time goes to zero, the process is done
If the process is non-interactive, put it aside onthe expired list
If the process is interactive, put it at the endof the current priority queue
If there’s nothing else at that priority, it willrun again immediately
Of course, by running so much is bonus will godown, and so will its priority and its interativestatus
There are two sets of 140 queues, active and expired
The system only runs processes from active queues, and puts them on expired queues when they use up their quanta
When a priority level of the active queue is empty, the scheduler looks for the next-highestpriority queue
After running all of the active queues, the active and expired queues are swapped
There are pointers to the current arrays; at theend of a cycle, the pointers are switched
struct prioarray *array = rq->active;if (array->nr_active == 0) { rq->active = rq->expired;rq->expired = array; }
Why is it done this way?
It avoids the need for traditional aging
Why is aging bad?
It’s O( n ) at each clock tick
Processes are touched only when they start orstop running
That’s when we recalculate priorities, bonuses,quanta, and interactive status
There are no loops over all processes or evenover all runnableprocesses
To rebalance, the kernel sometimes needs tomove processes from one runqueue to another
This is actually done by special kernel threads
Naturally, the runqueue must be locked beforethis happens
The kernel always locks runqueues in order ofincreasing address
Why? Deadlock prevention! (It is good forsomething...
