10 thoughts on “Lecture 6: CPU Scheduling”

1. Hi prof,
   Just wanted to clarify one small detail. The book says that when a process from the active list is blocked before the expiry of its time, it is placed back on the active list but with the time quantum equal to the time the process utilized in the earlier time quantum (i.e., reduced time quanta actually). And as you mentioned in the lecture, different priority levels have different time quanta, so it seems to be logical to assume that the priority for the process will be recomputed to account for the change in time quanta. However, in lecture slides, it is mentioned that priority is only recomputed when a process is moved from active to expired list. These two things appear to be contradictory (unless I am wrong which is very possible :P ). Will be grateful if you could please help me here :)

   • Shubham,

     There are two variables here, the allocated time quantum and the remaining time quantum. When a process blocks for I/O and is put back into the active list, the remaining time quantum becomes smaller, since the process spent some time running on the CPU. But the allocated time quantum for the process remains the same. When a process changes priority, the allocated time quantum changes, and the remaining time quantum is reset to full again.

     • Thanks for the prompt reply, prof. I understand what you say but I think I didn’t frame my question properly before :(
       So, the priority level of the process which was blocked for IO and didn’t utilize its quanta fully will change when it comes back to the ready state again?

       • Actually, no. The linux scheduler, as described on Page 750, rejoins the same queue after it blocks for I/O, with the same priority level.

         The priority level is recalculated using sleep_avg when moving from the active list to the expired list.

2. Errr…I am very confused now. I quote – “If the task blocks, for instance to wait for an I/O event, before its timeslice expires, once the event occurs and its execution can resume, it is placed back on the original active array, and its timeslice is decremented to reflect the CPU time it already consumed”. How can the task join the same priority level but has a decremented timeslice?? :O

   • Let me rephrase what the book says in the context of my reply above:

     If the task blocks, for instance to wait for an I/O event, before its used up all its allocated time quantum, once the event occurs and its execution can resume, it is placed back on the original active array at the same priority level as before, and its remaining time quantum is decremented to reflect the CPU time it already consumed

     • Oh, I see. I thought they they meant to decrement the next quantum available to the task. It was quite simple all the while :((

3. Hmm, i think that could mean giving the same MAX_quantum but time_left is reduced to account for the processing time b4 IO.

   However, im puzzled about them going to higher priority level. Whats the purpose of refilling its quantum again(when priority goes up) compared to using time_left when priority stays the same. im guessing the reason for increasing quantum is because after user enters input, increasing priority will make the OS more responsive. And thus, using the time_left as quantum will be a little conflicting because time_left might be too low and it defeats the purpose of increasing priority?

   Thanks :D

   • For Linux scheduler, the designer believes that higher priority processes tend to be interactive processes, and thus deserve to be allocated a larger time quantum to keep them in the active list longer. Thus a larger quantum is allocated to a process when its priority becomes higher.

     • In a priority queue, does quantum time affect process with different priority? Or it only affect the same priority level?

Comments are closed.